Managing blockchain-based trustable transaction services

ABSTRACT

Disclosed herein are methods, systems, and apparatus, including computer programs encoded on computer storage media, for managing blockchain-based trustable transaction services. One of the methods includes: storing order data of an order between a buyer and a seller on a blockchain of a blockchain network, the order data including one or more payment conditions, verifying that the buyer has a trustable automatic payment service guaranteed by a buyer financial institution, generating a smart contract for the order based on the order data on the blockchain, and executing the smart contract to automatically instruct the buyer financial institution to make a payment of the order for the buyer to the seller according to the trustable automatic payment service in response to determining that a payment condition for the payment specified in the smart contract is met based on order status data uploaded to the blockchain.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of PCT Application No.PCT/CN2020/120039, filed on Oct. 9, 2020, which is hereby incorporatedby reference in its entirety.

TECHNICAL FIELD

This specification relates to managing trustable transaction servicesbased on blockchain technology.

BACKGROUND

Distributed ledger systems (DLSs), which can also be referred to asconsensus networks, and/or blockchain networks, enable participatingentities to securely, and immutably store data. DLSs are commonlyreferred to as blockchain networks without referencing any particularuser case. Examples of types of blockchain networks can include publicblockchain networks, private blockchain networks, and consortiumblockchain networks. A consortium blockchain network is provided for aselect group of entities, which control the consensus process, andincludes an access control layer.

Digital networks have enabled people around the world to findinformation and interact with each other conveniently and efficiently,which have also driven a vigorous development of transactions, e.g.,trade including international trade or cross-border trade. However, intraditional transactions, transaction parties typically lack trust witheach other, especially international transactions or cross-bordertransactions where the transaction parties are distant from each otherand may have hardly any transaction history before. Although thetransaction parties can reach an agreement on transaction terms such aspayment terms in a contract or order, it is difficult to make sure thatthe transaction terms are met. For example, payment actions aregenerally controlled by buyers. Even if a buyer agrees to pay a seller,when to make the payment is still controlled by the buyer. Whether thebuyer has made the payment is not transparent or immediately availableto the seller, especially the payment involves international orcross-border money transfer between financial institutions in differentcountries or regions. In some cases, the seller can only confirm thatthe buyer has made the payment when the payment is actually received.Before that happens, the seller may have to manually or even repeatedlyrequest the payment or the status of the payment. In some cases, trustand trustable services have been implemented based on escrow systemsprovided by transaction platforms for the transaction parties. However,these implementations require the transaction parties to open escrowaccounts on the escrow systems and cannot use their own financialaccounts in their own financial institutions, which may cause them lackof trust and security. The transaction platforms also take great risksas guarantees for the escrow accounts.

Additionally, although the seller has trade orders and promised paymentsfrom the buyer, the seller has not able to use the trade orders toobtain financing from financial institutions because the lack oftrustable technologies for the financial institutions to verifyauthenticity of the trade orders.

Therefore, it would be desirable to develop new digital trustabletechnologies and systems that can create trust and provide trustabletransaction services, e.g., in international trade or cross-border tradefor multiple participants including trading parties and financialinstitutions.

SUMMARY

Described embodiments of the subject matter can include one or morefeatures, alone or in combination.

For example, in one embodiment, a system for managing blockchain-basedtrustable transaction services, including: a blockchain network of aplurality of trustable nodes that includes: a trading platform nodecorresponding to a trading platform for providing blockchain-basedtrustable trading services between a buyer and a seller, where the buyeris verified to have a trustable automatic payment service guaranteed bya buyer financial institution that automatically makes a payment onbehalf of the buyer in response to that a condition specified in a smartcontract deployed on a blockchain of the blockchain network is met; anda buyer financial institution node corresponding to the buyer financialinstitution. The trading platform node is configured to: store orderdata of an order on a corresponding blockchain for the order after theorder is confirmed by the buyer and the seller on the trading platform,the order data including one or more payment conditions for the order;and generate a corresponding smart contract for the order based on theorder data of the order, where the corresponding smart contract includesan automatic function that automatically instructs the buyer financialinstitution to make an order payment for the order to the seller inresponse to determining that a corresponding payment condition for theorder payment is met. The buyer financial institution node is configuredto: communicate with a computing device of the buyer financialinstitution to verify that the buyer has the trustable automatic paymentservice guaranteed by the buyer financial institution, and execute thecorresponding smart contract, where executing the corresponding smartcontract includes automatically instructing the computing device of thebuyer financial institution to make the order payment to the seller inresponse to determining that the corresponding payment condition for theorder payment is met.

In some embodiments, one or more of these general and specificembodiments may be implemented using a device, a system, a method, or acomputer-readable media, or any combination of devices, systems,methods, and computer-readable media. The foregoing and other describedembodiments can each, optionally, include one or more of the followingembodiments:

In some embodiments, one or more of these general and specificembodiments may be implemented using a device, a system, a method, or acomputer-readable media, or any combination of devices, systems,methods, and computer-readable media. The foregoing and other describedembodiments can each, optionally, include one or more of the followingembodiments:

In some embodiments, the buyer financial institution node is configuredto: receive order payment data confirming that the buyer financialinstitution has made the order payment to the seller; and store theorder payment data on the corresponding blockchain.

In some embodiments, the trading platform is configured to: receive theorder payment data from the corresponding blockchain; and feed back apayment status to the buyer and the seller based on the order paymentdata.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract to automatically instructthe computing device of the buyer financial institution to make theorder payment to the seller in response to determining that apredetermined time has reached or a predetermined time period has lapsedafter the corresponding payment condition for the order payment is met.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract to generate an automaticpayment command in response to determining that the correspondingpayment condition for the order payment is met; and transmit theautomatic payment command to the computing device of the buyer financialinstitution, the automatic payment command instructing the computingdevice of the buyer financial institution to make the order payment tothe seller according to the trustable automatic payment service.

In some embodiments, the buyer financial institution node is configuredto store order payment data on the corresponding blockchain, the orderpayment data confirming that the order payment has been made by thebuyer financial institution to the seller.

In some embodiments, the buyer has a buyer financial account in thebuyer financial institution, and the seller has a seller financialaccount in a seller financial institution, and the buyer financialinstitution node is configured to execute the corresponding smartcontract to automatically instruct the computing device of the buyerfinancial institution to make the order payment directly to the sellerfinancial account in the seller financial institution, without goingthrough the trading platform, in response to determining that thecorresponding payment condition for the order payment is met.

In some embodiments, the blockchain network of the plurality oftrustable nodes further includes a seller financial institution nodecorresponding to the seller financial institution.

In some embodiments, one of the buyer financial institution and theseller financial institution is an offshore entity, and the other one ofthe buyer financial institution and the seller financial institution isan onshore entity. The offshore entity and the onshore entity aresubject to different financial regulations, and the buyer financialinstitution node corresponding to the buyer financial institution andthe seller financial institution node corresponding to the sellerfinancial institution belong to the same blockchain network of theplurality of trustable nodes.

In some embodiments, the buyer financial institution node is configuredto: in response to the automatic payment command, transfer a digitalvalue corresponding to the order payment to the seller financialinstitution node.

In some embodiments, the seller financial institution node is configuredto: store payment reception data on the corresponding blockchain, thepayment reception data confirming that the order payment has beenreceived by the seller financial account in the seller financialinstitution from the buyer financial institution.

In some embodiments, the trading platform node is configured to: afterthe buyer logs in a buyer trading account on the trading platform,communicate with the buyer financial institution node to verify whethera buyer financial account of the buyer in the buyer financialinstitution is qualified for the trustable automatic payment service onthe trading platform, the buyer trading account including information ofthe buyer financial account.

In some embodiments, the trading platform is configured to: permit thebuyer to draft or review the order on the trading platform in responseto determining that the buyer financial account is qualified for thetrustable automatic payment service.

In some embodiments, the corresponding smart contract further includes:an order status update function that automatically updates a status ofthe order in response to determining the status of the order is changedbased on order status data uploaded to the corresponding blockchain.

In some embodiments, the order status data includes at least one oflogistics data, supplychain data, customs data, bill of landing data, orpayment data.

In some embodiments, the status of the order indicates at least one of:products associated with the order having been prepared or shipped bythe seller, the products having been inspected by a customs office, theproducts being transported by at least one logistics provider, a bill oflanding associated with the order having been submitted by the seller onthe trading platform, the submitted bill of landing having beenconfirmed by the buyer on the trading platform, an invoice associatedwith the order having been generated by the blockchain network, thegenerated invoice having been confirmed by the buyer, a consensus havingbeen reached between the buyer and the seller on the order, theautomatic payment having been made by the buyer financial institution,the automatic payment having been received by the seller, or theproducts having been received by the buyer.

In some embodiments, the blockchain network of the plurality oftrustable nodes further includes at least one of: a customs office nodecorresponding to a customs office, where the order status data includescustom data uploaded to the corresponding blockchain by the customsoffice node, or a logistic provider node corresponding to at least onelogistics provider, where the order status data include logistic datauploaded to the corresponding blockchain by the logistic provide node.

In some embodiments, the one or more payment conditions includes a firstpayment condition for a first payment for the order and a second paymentcondition for a second payment for the order. The buyer financialinstitution node is configured to: execute the corresponding smartcontract to automatically instruct the computing device of the buyerfinancial institution to make the first payment to the seller inresponse to determining that the first condition for the first paymentis met, and execute the corresponding smart contract to automaticallyinstruct the computing device of the buyer financial institution to makethe second payment to the seller in response to determining that thesecond condition for the second payment is met.

In some embodiments, the first payment is an initial payment of theorder, and the first payment condition includes the order having beenvalidated on the trading platform, and the second payment is a remainingpayment of the order, and the second payment condition includes at leastone of: a bill of landing associated with the order having beensubmitted by the seller on the trading platform, the submitted bill oflanding having been confirmed by the buyer on the trading platform, aninvoice associated with the order having been generated by theblockchain network, the generated invoice having been confirmed by thebuyer, or a consensus having been reached between the buyer and theseller on the order.

In some embodiments, the system includes the trading platform.

In some embodiments, the trading platform node is configured to generatethe corresponding smart contract for the order from a smart contracttemplate based on the order data, the smart contract template includinga plurality of functions for the trustable trading services, and ingenerating the corresponding smart contract for the order, the tradingplatform node is configured to call one or more of the plurality offunctions in the smart contract template and use the order data as inputto the one or more of the plurality of functions in the smart contracttemplate.

For example, in another embodiment, a system for managingblockchain-based trustable transaction services, including: a blockchainnetwork of a plurality of trustable nodes that includes: a tradingplatform node corresponding to a trading platform for providingblockchain-based trustable trading services between a buyer and aseller, where the buyer is verified to have a trustable undertaking (TU)service guaranteed by a buyer financial institution that automaticallymakes a payment for the buyer to the seller based on a credit of thebuyer in the buyer financial institution in response to that a conditionspecified in a smart contract deployed on a blockchain of the blockchainnetwork is met; and a buyer financial institution node corresponding tothe buyer financial institution. The trading platform node is configuredto: store order data of an order on a corresponding blockchain of theblockchain network for the order after the order is confirmed by thebuyer and the seller on the trading platform, the order data includingone or more payment conditions for the order and TU service datarepresenting a corresponding TU service for the order, and generate acorresponding smart contract for the order based on the order data ofthe order, where the corresponding smart contract includes an automaticfunction that automatically instructs the buyer financial institution tomake an order payment for the order to the seller according to thecorresponding TU service for the order in response to determining that acorresponding payment condition for the order payment is met. The buyerfinancial institution node is configured to: communicate with acomputing device of the buyer financial institution to verify that thebuyer has the corresponding TU service for the order guaranteed by thebuyer financial institution, and execute the corresponding smartcontract, where executing the corresponding smart contract includesautomatically instructing the computing device of the buyer financialinstitution to make the order payment to the seller according to thecorresponding TU service in response to determining that thecorresponding payment condition for the order payment is met.

In some embodiments, one or more of these general and specificembodiments may be implemented using a device, a system, a method, or acomputer-readable media, or any combination of devices, systems,methods, and computer-readable media. The foregoing and other describedembodiments can each, optionally, include one or more of the followingembodiments:

In some embodiments, the buyer financial institution node is configuredto: receive order payment data confirming that the buyer financialinstitution has successfully made the order payment to the selleraccording to the corresponding TU service for the order; and store theorder payment data on the corresponding blockchain.

In some embodiments, the blockchain network of the plurality oftrustable nodes further includes a seller financial institution nodecorresponding to a seller financial institution. The seller has a sellerfinancial account in the seller financial institution, and the sellerfinancial institution node is configured to store payment reception dataon the corresponding blockchain, the payment reception data confirmingthat the order payment for the order has been received by the sellerfinancial account in the seller financial institution from the buyerfinancial institution.

In some embodiments, the trading platform node is configured to:determine, based on the TU service data, that the buyer selects to usethe corresponding TU service for the order on the trading platform, andtransmit a request to the computing device of the buyer financialinstitution through the buyer financial institution node, the requestrequesting the buy financial institution to verify whether the buyer isqualified for the corresponding TU service for the order guaranteed bythe buyer financial institution.

In some embodiments, the trading platform is configured to provide auser interface for receiving user input of the order data, and the userinterface includes a selection to use the corresponding TU service forthe order.

In some embodiments, the buyer financial institution node is configuredto: receive verification data from the computing device of the buyerfinancial institution, the verification data confirming that the buyerhas the corresponding TU service for the order guaranteed by the buyerfinancial institution, and store the verification data on thecorresponding blockchain.

In some embodiments, the trading platform is configured to: determine,based on the verification data stored on the corresponding blockchain,that the buyer has the corresponding TU service for the order guaranteedby the buyer financial institution, and validate the order afterdetermining that the buyer has the corresponding TU service for theorder guaranteed by the buyer financial institution.

In some embodiments, the trading platform node is configured to transmitthe request after storing the order data of the order on thecorresponding blockchain.

In some embodiments, the corresponding payment condition for the orderpayment is determined based on the corresponding TU service for theorder.

In some embodiments, the buyer financial institution node is configuredto execute the corresponding smart contract to automatically instructthe computing device of the buyer financial institution to make theorder payment to the seller according to the corresponding TU servicefor the order in response to determining that a predetermined time hasreached or a predetermined time period has lapsed after thecorresponding payment condition for the order payment is met.

In some embodiments, the predetermined time or the predetermined timeperiod is determined based on the corresponding TU service for theorder.

In some embodiments, the one or more payment conditions includes a firstpayment condition for a first payment for the order and a second paymentcondition for a second payment for the order. The second payment is theorder payment made according to the corresponding TU service, and thesecond payment condition includes the corresponding payment condition.The buyer financial institution node is configured to execute thecorresponding smart contract to automatically instruct the computingdevice of the buyer financial institution to make the second payment tothe seller according to the corresponding TU service for the order inresponse to determining that the second payment condition for the secondpayment is met.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract to automatically instructthe computing device of the buyer financial institution to make thefirst payment to the seller according to a trustable automatic paymentservice for the buyer provided by the buyer financial institution inresponse to determining that the first payment condition for the firstpayment is met.

In some embodiments, the trading platform node is configured to: afterthe buyer logs in a buyer trading account on the trading platform,communicate with the computing device of the buyer financial institutionthrough the buyer financial institution node to verify whether a buyerfinancial account of the buyer in the buyer financial institution isqualified for the trustable automatic payment service, the buyer tradingaccount including information of the buyer financial account.

In some embodiments, the first payment is an initial payment for theorder, and the first payment condition includes a validation of theorder. The second payment is a remaining payment for the order, and thesecond payment condition includes at least one of: a bill of landingassociated with the order having been submitted by the seller on thetrading platform, the submitted bill of landing having been confirmed bythe buyer on the trading platform, an invoice associated with the orderhaving been generated by the blockchain network, the generated invoicehaving been confirmed by the buyer, or a consensus having been reachedbetween the buyer and the seller on the order.

In some embodiments, the corresponding smart contract further includesan order status update function that automatically updates a status ofthe order in response to determining the status of the order is changedbased on order status data uploaded to the corresponding blockchain.

In some embodiments, the status of the order indicates at least one of:products associated with the order having been prepared or shipped bythe seller, the products having been inspected by a customs office, theproducts being transported by at least one logistics provider, a bill oflanding associated with the order having been submitted by the seller onthe trading platform, the submitted bill of landing having beenconfirmed by the buyer on the trading platform, an invoice associatedwith the order having been generated by the blockchain network, thegenerated invoice having been confirmed by the buyer, a consensus havingbeen reached between the buyer and the seller on the order, theautomatic payment having been made by the buyer financial institution,the automatic payment having been received by the seller, or theproducts having been received by the buyer.

In some embodiments, the blockchain networks of the plurality oftrustable nodes further includes at least one of: a customs office nodecorresponding to the customs office, the order status data includingcustom data uploaded to the corresponding blockchain by the customsoffice node, or a logistic provider node corresponding to the at leastone logistics provider, the order status data including logistic datauploaded to the corresponding blockchain by the logistic provide node.

In some embodiments, the order status data includes at least one oflogistics data, supplychain data, customs data, bill of landing data, orpayment data.

In some embodiments, the system includes the trading platform.

For example, in another embodiment, a system for managingblockchain-based trustable transaction services, including: a blockchainnetwork of a plurality of trustable nodes that includes: a tradingplatform node corresponding to a trading platform for providingblockchain-based trustable trading services between a buyer and aseller, where the buyer has a buyer financial account in a buyerfinancial institution, and the seller has a seller financial account ina seller financial institution, and where the buyer is verified to havea trustable undertaking (TU) service guaranteed by the buyer financialinstitution that automatically makes a payment for the buyer based on acredit of the buyer in the buyer financial institution in response tothat a condition specified in a smart contract deployed on a blockchainof the blockchain network is met; a buyer financial institution nodecorresponding to the buyer financial institution; and a seller financialinstitution node corresponding to the seller financial institution. Thetrading platform node is configured to: store order data of an order ona corresponding blockchain of the blockchain network for the order afterthe order is confirmed by the buyer and the seller on the tradingplatform, the order data including one or more payment conditions forthe order and data representing a corresponding TU service for theorder, generate a trustable undertaking certificate for the order basedon the TU service data, the trustable undertaking certificate includingan amount of the order payment for the order, and store the trustableundertaking certificate for the order on the blockchain. The sellerfinancial institution node is configured to: transmit the trustableundertaking certificate to a computing device of the seller financialinstitution to determine whether to approve a financing request of theseller based on the trustable undertaking certificate.

In some embodiments, one or more of these general and specificembodiments may be implemented using a device, a system, a method, or acomputer-readable media, or any combination of devices, systems,methods, and computer-readable media. The foregoing and other describedembodiments can each, optionally, include one or more of the followingembodiments:

In some embodiments, one of the buyer financial institution and theseller financial institution is an offshore entity, and the other one ofthe buyer financial institution and the seller financial institution isan onshore entity. The offshore entity and the onshore entity aresubject to different financial regulations. The buyer financialinstitution node corresponding to the buyer financial institution andthe seller financial institution node corresponding to the sellerfinancial institution belong to the same blockchain network of theplurality of trustable nodes.

In some embodiments, the seller financial institution node is configuredto: receive approval data from the computing device of the sellerfinancial institution, the approval data indicating that the sellerfinancial institution has approved the financing request of the sellerfor a financing amount based on the trustable undertaking certificate,and store the approval data on the blockchain, where the approval datareferences the trustable undertaking certificate.

In some embodiments, the seller financial institution node is configuredto: receive financing payment data from the computing device of theseller financial institution, the financing payment data confirming thata financing amount associated with the financing request has been paidby the seller financial account in the seller financial institution, andstore the financing payment data on the blockchain.

In some embodiments, the trustable undertaking certificate includes atleast one of: an identifier of the trustable undertaking certificate, aneffective time of the trustable undertaking certificate, thecorresponding payment condition for the order payment, information ofthe order including at least one of an order identifier, a total cost ofthe order, or product information, logistics information for the orderincluding at least one of a shipping method, a trade term, a shippingcost, or a shipping insurance cost, information of the buyer and theseller, information of the buyer financial institution and the sellerfinancial institution, or information of the buyer financial account inthe buyer financial institution and the seller financial account in theseller financial institution.

In some embodiments, the seller financial institution node is configuredto: receive payment reception data from the computing device of theseller financial institution, the payment reception data confirming thatthe order payment for the order has been received by the sellerfinancial account in the seller financial institution from the buyerfinancial institution, and store the payment reception data on theblockchain.

In some embodiments, the trading platform node is configured to:generate a corresponding smart contract for the order based on the orderdata of the order. The corresponding smart contract includes anautomatic function that automatically instructs the buyer financialinstitution to make an order payment for the order to the selleraccording to the corresponding TU service for the order in response todetermining that a corresponding payment condition for the order paymentis met.

In some embodiments, the trading platform node is configured to: verifywhether the buyer is authorized for the corresponding TU service for theorder on the trading platform with a computing device of the buyerfinancial institution through the buyer financial institution node.

In some embodiments, generating the trustable undertaking certificatefor the order on the blockchain is in response to verifying that thebuyer is authorized for the corresponding TU service for the orderguaranteed by the buyer financial institution.

In some embodiments, the trading platform node is configure to submit averification request with the trustable undertaking certificate to acomputing device of the buyer financial institution through the buyerfinancial institution node, and the buyer financial institution isconfigured to verify whether the buyer is authorized for thecorresponding TU service for the order based on the trustableundertaking certificate.

In some embodiments, the trading platform node is configured to: inresponse to verifying that the buyer is authorized for the correspondingTU service for the order guaranteed by the buyer financial institution,transmit a verification message to the trading platform confirming thatthe buyer is authorized for the corresponding TU service for the order.

In some embodiments, the trading platform is configured to validate theorder after receiving the verification message from the trading platformnode.

In some embodiments, the trading platform node is configured to transmitthe verification request after storing the order data of the order onthe blockchain.

In some embodiments, the corresponding payment condition is determinedbased on the corresponding TU service for the order.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract, where executing thecorresponding smart contract includes automatically instructing thecomputing device of the buyer financial institution to make the orderpayment to the seller according to the corresponding TU service for theorder in response to determining that the corresponding paymentcondition for the order payment is met.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract to generate an automaticpayment command in response to determining that the correspondingpayment condition for the order payment is met, the automatic paymentcommand instructing the computing device of the buyer financialinstitution to make the order payment to the seller according to thecorresponding trustable undertaking service for the order; and transmitthe automatic payment command to the computing device of the buyerfinancial institution.

In some embodiments, the blockchain network is configured to: executethe corresponding smart contract to automatically instruct the computingdevice of the buyer financial institution to make the order payment tothe seller according to the corresponding TU service for the order inresponse to determining that a predetermined time has reached or apredetermined time period has lapsed after the corresponding paymentcondition is met.

In some embodiments, the predetermined time or the predetermined timeperiod is determined based on the corresponding TU service for theorder.

In some embodiments, the one or more payment conditions includes a firstpayment condition for a first payment for the order and a second paymentcondition for a second payment for the order. The second payment is theorder payment made according to the TU service for the order, and thesecond condition includes the corresponding payment condition.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract to automatically instructthe computing device of the buyer financial institution to make thefirst payment to the seller according to a trustable automatic paymentservice for the buyer provided by the buyer financial institution inresponse to determining that the first payment condition for the firstpayment is met, and execute the corresponding smart contract toautomatically instruct the computing device of the buyer financialinstitution to make the second payment to the seller according to thecorresponding TU service for the order in response to determining thatthe second payment condition for the second payment is met.

In some embodiments, the first payment is an initial payment for theorder, and the first payment condition includes a validation of theorder. The second payment is a remaining payment for the order, and thesecond payment condition includes at least one of: a bill of landingassociated with the order having been submitted by the seller on thetrading platform, the submitted bill of landing having been confirmed bythe buyer on the trading platform, an invoice associated with the orderhaving been generated by the blockchain network, the generated invoicehaving been confirmed by the buyer, or a consensus having been reachedbetween the buyer and the seller on the order.

In some embodiments, the trading platform node is configured to: afterthe buyer logs in a buyer trading account on the trading platform,communicate with the computing device of the buyer financial institutionthrough the buyer financial institution node to verify whether a buyerfinancial account of the buyer in the buyer financial institution isqualified for the trustable automatic payment service, the buyer tradingaccount including information of the buyer financial account.

In some embodiments, the corresponding smart contract further includesan order status update function that automatically updates a status ofthe order in response to determining the status of the order is changedbased on order status data uploaded to the corresponding blockchain.

In some embodiments, the status of the order indicates at least one of:products associated with the order having been prepared or shipped bythe seller, the products having been inspected by a customs office, theproducts being transported by at least one logistics provider, a bill oflanding associated with the order having been submitted by the seller onthe trading platform, the submitted bill of landing having beenconfirmed by the buyer on the trading platform, an invoice associatedwith the order having been generated by the blockchain network, thegenerated invoice having been confirmed by the buyer, a consensus havingbeen reached between the buyer and the seller on the order, theautomatic payment having been made by the buyer financial institution,the automatic payment having been received by the seller, or theproducts having been received by the buyer.

In some embodiments, the blockchain networks of the plurality oftrustable nodes further includes at least one of: a customs office nodecorresponding to the customs office, the order status data includingcustom data uploaded to the corresponding blockchain by the customsoffice node, or a logistic provider node corresponding to the at leastone logistics provider, the order status data including logistic datauploaded to the corresponding blockchain by the logistic provide node.

In some embodiments, the order status data includes at least one oflogistics data, supplychain data, customs data, bill of landing data, orpayment data.

In some embodiments, the system includes the trading platform.

It is appreciated that methods in accordance with this specification mayinclude any combination of the embodiments described herein. That is,methods in accordance with this specification are not limited to thecombinations of embodiments specifically described herein, but alsoinclude any combination of the embodiments provided.

The details of one or more embodiments of this specification are setforth in the accompanying drawings and the description below. Otherembodiments and advantages of this specification will be apparent fromthe description and drawings, and from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram illustrating an example of an environment that canbe used to execute embodiments of this specification.

FIG. 2 is a diagram illustrating an example of an architecture inaccordance with embodiments of this specification.

FIG. 3 is a diagram illustrating an example of a blockchain-basedtrustable transaction system implementing blockchain-based trustabletrading services in accordance with embodiments of this specification.

FIG. 4 is a diagram illustrating an example of a user interface of atrading platform for implementing trustable trading services inaccordance with embodiments of this specification.

FIG. 5 is a flowchart illustrating an example of a process forimplementing blockchain-based trustable transaction services that can beexecuted in accordance with embodiments of this specification.

FIG. 6 is a flowchart illustrating an example of a process forimplementing blockchain-based trustable transaction services that can beexecuted in accordance with embodiments of this specification.

FIG. 7 is a flowchart illustrating an example of a process forimplementing blockchain-based trustable transaction services that can beexecuted in accordance with embodiments of this specification.

FIG. 8 is a diagram illustrating an example of a blockchain tradeinvoice in accordance with embodiments of this specification.

FIG. 9 is a diagram illustrating an example of a trustable undertakingcertificate in accordance with embodiments of this specification.

FIG. 10 is a flowchart illustrating an example of a process forimplementing blockchain-based trustable transaction services withdifferent payment conditions that can be executed in accordance withembodiments of this specification.

FIG. 11 is a flowchart illustrating an example of a process forimplementing blockchain-based trustable transaction services with aconsensus payment condition that can be executed in accordance withembodiments of this specification.

FIG. 12 show a diagram illustrating steps in the processes of FIG. 10 orFIG. 11 in accordance with embodiments of this specification.

FIG. 13A is a flowchart illustrating an example of a process inaccordance with embodiments of this specification.

FIG. 13B is a flowchart illustrating an example of a process inaccordance with embodiments of this specification.

FIG. 13C is a flowchart illustrating an example of a process inaccordance with embodiments of this specification.

FIG. 14A depicts examples of modules of an apparatus in accordance withembodiments of this specification.

FIG. 14B depicts examples of modules of another apparatus in accordancewith embodiments of this specification.

FIG. 14C depicts examples of modules of another apparatus in accordancewith embodiments of this specification.

Like reference numbers and designations in the various drawings indicatelike elements.

DETAILED DESCRIPTION

This specification describes technologies for managing trustabletransaction services based on a new blockchain architecture thatenhances several aspects of data exchange between possibly unaffiliatedentities. The trustable transaction services can include tradingservices, payment services, financing services, data exchange services,or any other transaction services. These technologies can implement anew trustable transaction (e.g., trading and financing) service systemby integrating a number of trustable nodes into a blockchain network toprovide trustable transaction services to transaction entities (e.g.,trading parties), especially for international order or cross-bordertransactions. These technologies can create a trustable transactionplatform that allow transaction parties, e.g., small and medium-sizeenterprises (SMEs), which may be unaffiliated and have no or weak trustbefore, to be able to communicate and conduct business with each otherin a reliable and efficient manner. These technologies can bridge thetrust gap between the transaction parties and connect them through atransaction platform. The technologies can integrate the transactionplatform, financial institutions such as offshore banks and onshorebanks, customs offices, logistics providers, and/or any other relevantentities as the network nodes in the blockchain network to create a newecosystem, for example, for providing trusted digital international orcross-border transactions. The new ecosystem improves upon priortransaction systems in several ways. For example, implementations of thetechnologies described in this specification can provide more secure,reliable efficient, convenient, diversified, inclusive, and transparenttransaction services. The new ecosystem also implements a system thatenhances trust between the transaction parties and trust betweenenterprises and financial institutions. The new ecosystem can maketransactions more secure and reliable, make financial loans transparentand credible or valid, and make services efficient and convenient oreffective. For illustration purposes, in this specification, a tradingservice (that can also include a financial service such as a paymentservice) is described as an example of a transaction service; a tradingplatform or system is described as an example of a transaction platformor system, an order (e.g., a purchase order or another trade order) isdescribed as an example of a transaction between transaction entities;and a buyer and a seller is described as an example of a pair oftransaction entities. The described techniques can be applied toadditional or different examples of transaction services.

The techniques can overcome well-known problems with conventionaltransaction systems (e.g., trading systems), such as weak orinsufficient trust between participants, low efficiency, low degree ofdigitization, high transaction cost, long payment turnover, financingpressures on enterprises such as SMEs, and lack of transparency. Forexample, the techniques implemented herein can avoid complex offlineprocesses and reviewing and can make a trade, especially internationalor cross-border trade, with lower transactional cost, automaticsettlements, easy access to enterprises' credit, and authenticatedorders and counterparties. The technologies can mitigate trade risk,e.g., mitigate uncertainties (such as in shipping products and makingpayments) and risks by using traceable trade data and trustableautomatic payment services, and help deliver inclusive and efficientfinancial services. The technologies can create a next generation globaltransaction system to serve global entities such as enterprisesincluding SMEs.

The techniques described in this specification produce several technicaleffects. In some embodiments, the technologies can establish a newblockchain-based trading system with hardware and software thatintegrate a selected groups of network nodes to build a blockchainnetwork. The selected groups of network nodes can include, for example,computer systems of one or more trading platform, financial institutionsof trading parties, and one or more customs offices, logisticsproviders. The selected network nodes are trustable nodes with enhancedtrust guaranteed by consensus processes and data immutability,reliability, transparency, traceability, and verifiability in theestablished blockchain network. In some embodiments, the blockchainnetwork can be, for example, a consortium blockchain network, withadditional safeguard in controlling whether an entities can be jointedas a network node of the blockchain network for providing trustabletransaction services. In some embodiments, the technologies canestablish achieve enhanced data security, provide more secure andreliable communication channels, reduce latency in data transmission,order operation triggering, and confirmation receiving to providetrustable trading services. In some embodiments, the technologies candefine and deploy one or more smart contracts the smart contracts onblockchains of the blockchain network to automatically trigger paymentand other trading operations and enable trustable trading services. Forexample, once a buyer and a seller (or a supplier) generate (or confirm)a trade order on a trading platform, the order can be automaticallyuploaded and recorded on a blockchain of the blockchain network, whichis traceable and tamperproof. The order can include order details suchas order terms, one or more payment conditions, and a payment time. Acorresponding smart contract can be generated once the order is recordedon the blockchain. As the order is executed, the smart contract can beautomatically executed to track and update order status data transmittedby the trustable nodes in the blockchain network. The order status datacan include, for example, order placement data, logistics data, customsdata, payment data, and tax refund option information. Using theblockchain, the buyer financial institution and seller financialinstitution can automatically process the payment settlements throughthe smart contract. For example, the smart contract can include anautomatic function that automatically instructs the buyer financialinstitution to make a payment for the order to the seller in response todetermining that a corresponding payment condition for the payment ismet. The automatic triggering and immutability features of the smartcontract can enhance the seller's trust and assurance in the payment ofthe order and be more willing to conduct business with the seller.

In some embodiments, the buyer's payment can be backed or guaranteed bythe buyer financial institution to further enhance the trust. In somecases, the buyer is verified to have a trustable automatic payment (AP)service guaranteed by the buyer financial institution that automaticallymakes a payment on behalf of the buyer in response to that the paymentcondition specified in the smart contract on the blockchain is met.According to the trustable AP service, a computing device of the buyerfinancial institution automatically executes an action to make a paymenttransaction without receiving an authorization or confirmation from thebuyer in response to that the payment condition specified in the smartcontract on the blockchain is met. In some cases, the buyer is verifiedto have a trustable undertaking (TU) service, e.g., a bank paymentundertaking (BPU) service, guaranteed by the buyer financial institutionthat automatically makes the payment for the buyer to the seller basedon a credit of the buyer in the buyer financial institution in responseto that the condition specified in the smart contract on the blockchainis met. According to the TU service, the computing device of the buyerfinancial institution executes an action to make a payment transactionno matter whether the buyer financial account has enough money or fundin the buyer financial institution and without receiving anauthorization or confirmation from the buyer.

In some embodiments, the technologies can improve efficiency and reducelatency in a sequence of operations in a trading order (includingproduct shipping, different stages of payments, payment confirmation,etc.). In some embodiments, the sequence of operations in a particulartrading order can be written into a smart contract customized for thetrading order, with defined triggering conditions. Once the triggerconditions are satisfied, the smart contract can automatically trigger anext operation and thus reduce the processing latency and ensure orderedexecution of the trading process. In addition, during the actualexecution of the trading order, data related to the trading order (e.g.,logistics data and payment data) can be uploaded and stored in theblockchain, for example, by the trustable nodes in real time orsubstantially real time. The smart contract can receive the data (asinput to trigger further operations) and track and update the status ofthe trading order based on the received data. Each of the trustablenodes in the blockchain network can have transparency and trust in theorder status and order data stored in the blockchain. As an example,payment confirmation data from the buyer financial institution and/orpayment reception data from the seller financial institution can betimely returned and recorded on the blockchain and made available toother trustable nodes in the blockchain network. For example, thetrading platform can receive the payment confirmation data and/orpayment reception data instantaneously and feed back the payment statusto the buyer and the seller. In such a way, the payment for the ordercan be guaranteed and the latency of payment confirmation can bereduced, which can make the payment more efficient and transparent. Thetrust between the buyer and the seller can be built and increased. Thebuyers' and suppliers' on-chain trust can continue to accumulate.

In some embodiments, the technologies can enable trustable financingservices for buyers. For example, the buyer can apply for acorresponding TU service from a buyer financial institution for an orderto be made with a seller. The buyer financial institution can verifywhether the buyer is qualified for the TU service for the order, forexample, based on a credit of the buyer in the buyer financialinstitution. If the buyer is verified to be qualified for the TUservice, the buyer financial institution can make a payment commitmentand guarantee (or promise) to make a payment for the order to the selleronce the payment condition is met. In such a way, the TU service canconvert the buyer's credit in the buyer financial institution into acredit of the buyer financial institution, which can increase thecredibility and leverage of the buyer in the trade. Thus, the buyer canuse the TU service to negotiate better order terms, e.g., payment termssuch as longer payment time. The TU service can capitalize the buyer'scredit in the buyer financial institution, and can use the buyerfinancial institution's guarantee to increase the buyer's credit in thetrade. For example, the blockchain network can generate a trustableundertaking certificate for the order based on, for example, order data,logistics data, customs data, and/or invoice data. The resultingtrustable undertaking certificate can be deposited, transferred, andtraded on the blockchain like an asset. The buyer can ask the buyerfinancial institution to provide the TU service for the order based onthe trustable undertaking certificate.

In some embodiments, the technologies can enable trustable financingservices for sellers. For example, with the TU service guaranteed by thebuyer financial institution, the seller does not need to concern aboutwhether the buyer would make the payment from after the seller shipsproducts, and can have certainty that the payment would be made by thebuyer financial institution to ensure funding liquidity and security ofthe seller. The trustable financing services can also help the sellersecure more financing based on the TU-backed trade orders. As anexample, when the seller has financing needs, the seller can submit afinancial request, e.g., for a financial loan, to the seller financialinstitution. The seller financial institution can verify whether theseller is qualified for the financial loan based on on-chain trust ofthe trading parties, e.g., the trustable undertaking certificategenerated on the blockchain. In some embodiments, the trustableundertaking certificate can function as receivables of the seller, andbe regarded as any other types of assets of the seller that can betransferred or used for financing. In some embodiments, the sellerfinancial institution can submit verification requests to the blockchainnetwork to check credible trade data on the blockchain and obtain thetrustable undertaking certificate, or the seller can submit thefinancial request with the trustable undertaking certificate. If theseller financial institution verifies that the seller is qualified forthe financial loan, the seller can get the financial loan for itsfinancial needs. The seller can repay the financial loan, e.g., with thepayment received from the buyer financial institution according to theTU service for the order.

In some embodiments, the technologies can provide trustable tradingservices of trading, for example, to a large number of trading parties,through a unified, more user friendly interface, while reducing theinfrastructure cost and operating cost of the trading entities. In someembodiments, the buyer and the seller do not join the blockchain networkas the trustable nodes. Instead, the trading platform, as a trustablenode in the blockchain network, can serve as the common interface of abuyer and a seller, and provide secure and trustable trading servicesbetween the buyer and the seller. However, in some embodiments, thetrading platform does not need to act as an escrow system between thebuyer and the seller, and the buyer and the seller do not need to opentheir own financing or monetary accounts in the trading platform to makepayments. Instead, the buyer and the seller can exchange money or makepayment using their own bank accounts with their respective banks end toend without channeling the money or other type of payment through thetrading platform, which can be more efficient and reliable. In this way,the trading platform can scale to accommodate a large number of buyersand sellers, can save the buyers' and sellers' operating expenses (OPEX)in continuing with their respective financial instructions, without theneed to open new financing or monetary accounts. On other hand, thelarge number of buyers and sellers can enjoy the blockchain-basedtrustable trading services, without itself joining the blockchainnetwork as a network node, which in turn saves the infrastructure costby limiting the trustable nodes to the trading platform, one or morefinancial institutions, logistics providers, customs offices, and/or anyrelevant parties that can serve multiple buyers and sellers. Such astructure of the blockchain-based trading platform can also and improveoperational efficiency of the blockchain network by reducing networktraffic and computational load in performing consensus before storingdata into the blockchain of the blockchain network. The technologies canprovide more opportunities to trading platforms or trading marketplaces,to trading parties, to financial institutions, to logistics providers,to customs offices, and/or to any relevant parties.

In some embodiments, the technologies provide additional capabilitiesfor making trustable connections between possibly unaffiliated entities.For example, the technologies can connect the trading platforms withbuyer financial institutions, seller financial institutions, logisticsproviders or companies, or supplychain companies to build a trustabletrade network in the form of a blockchain alliance to provide guaranteetrade services. The technologies can make the trading and financingservices have the traceable, decentralized, immutable, and transparentfeatures, with which all participants (or parties) on the blockchain areable to build a better trust system. The trust system can allow tradingto be made and assets or credits to be transferred more reliably andefficiently.

In some embodiments, the technologies can enhance the security andconvenience of performing electronic transactions. For example, thetechnologies can provide secure and convenient transactions, smart andinclusive finance, efficient and digital order management. In someembodiments, the technologies can make data on the blockchain as thesource of truth by distributing the control fairly to parties to use thesystem with the transparency of the transaction history. Throughupstream and downstream cross-validation, uploading source data to ablockchain, and blockchain consensus mechanisms, the authenticity of thedata on the blockchain can be guaranteed, so that trade participants canefficiently obtain real trade data from the blockchain and improvecollaboration efficiency. In some embodiments, the blockchain networkcan generate a blockchain trade invoice that can integrate real tradedata on the blockchain to form a voucher. The voucher can be used as abasis for verification of trade authenticity by participants, as well asa transaction voucher for buyers and sellers, and even as a basis forpayment. The blockchain trade invoice can be used to verify theauthenticity of trade, without complex offline processes andrequirements of a variety of certification materials and paperwork.

To provide further context for embodiments of this specification, and asintroduced above, distributed ledger systems (DLSs), which can also bereferred to as consensus networks (e.g., made up of peer-to-peer nodes),and blockchain networks, enable participating entities to securely, andimmutably conduct transactions, and store data. Although the termblockchain is generally associated with particular networks, and/or usecases, blockchain is used herein to generally refer to a DLS withoutreference to any particular use case.

A blockchain is a data structure that stores transactions in a way thatthe transactions are immutable. Thus, transactions recorded on ablockchain are reliable and trustworthy. A blockchain includes one ormore blocks. Each block in the chain is linked to a previous blockimmediately before it in the chain by including a hash of the previousblock. Each block also includes a local timestamp (e.g., provided by acomputing device that generates the block or a computing system thatmanages the blockchain), its own hash, and one or more transactions. Forexample, the block can include a block header and a block body. Theblock header can include the local timestamp, its own hash, and a hashof the previous block. The block body can include payload informationsuch as the one or more transactions (or transaction data). Thetransactions, which have already been verified by the nodes of theblockchain network, are hashed and encoded into a Merkle tree. A Merkletree is a data structure in which data at the leaf nodes of the tree ishashed, and all hashes in each branch of the tree are concatenated atthe root of the branch. This process continues up the tree to the rootof the entire tree, which stores a hash that is representative of alldata in the tree. A hash purporting to be of a transaction stored in thetree can be quickly verified by determining whether it is consistentwith the structure of the tree.

Whereas a blockchain is a decentralized or at least partiallydecentralized data structure for storing transactions, a blockchainnetwork is a network of computing nodes that manage, update, andmaintain one or more blockchains by broadcasting, verifying andvalidating transactions, etc. As introduced above, a blockchain networkcan be provided as a public blockchain network, a private blockchainnetwork, or a consortium blockchain network.

In general, a consortium blockchain network is private among theparticipating entities. In a consortium blockchain network, theconsensus process is controlled by an authorized set of nodes, which canbe referred to as consensus nodes, one or more consensus nodes beingoperated by a respective entity (e.g., a financial institution,insurance company). For example, a consortium of ten (10) entities(e.g., financial institutions, insurance companies) can operate aconsortium blockchain network, each of which operates at least one nodein the consortium blockchain network. In some examples, within aconsortium blockchain network, a global blockchain is provided as ablockchain that is replicated across all nodes. That is, all consensusnodes are in perfect state consensus with respect to the globalblockchain. To achieve consensus (e.g., agreement to the addition of ablock to a blockchain), a consensus protocol is implemented within theconsortium blockchain network. For example, the consortium blockchainnetwork can implement a practical Byzantine fault tolerance (PBFT)consensus, described in further detail below.

In some embodiments, a centralized ledger system can also adopt the datastructure of a blockchain to leverage immutability, reliability, andtrustworthiness of data stored on a blockchain. In some embodiments,such a centralized ledger system can be referred to as ablockchain-based centralized ledger system or a universal auditableledger service system. In some embodiments, the blockchain-basedcentralized ledger system can include a central trusted authority thatprovides transparent, immutable, and cryptographically verifiable datathat are stored in blocks of a blockchain data structure. The storeddata can be in a log format, including, for example, not only fortransaction logs but also other transaction data and block data. Due tothe existence of the central trusted authority, the blockchain-basedcentralized ledger system does not need to perform consensus processesto establish trust. In some embodiments, the blockchain-basedcentralized ledger system can be more efficient compared to a typicalblockchain-based distributed or decentralized ledger system. In someembodiments, the blockchain-based centralized ledger system can providea cloud-based storage service with enhanced trust, efficiency, andstorage performance.

In some embodiments, the centralized ledger system can be a node of ablockchain network. For example, the centralized ledger system can be anon-consensus node in the blockchain network and can provide highlyreliable and high-performance auditable streaming ledger services forthe consensus nodes or other non-consensus nodes in the blockchainnetwork, or entities outside of the blockchain network.

FIG. 1 is a diagram illustrating an example of an environment 100 thatcan be used to execute embodiments of this specification. In someexamples, the environment 100 enables entities to participate in aconsortium blockchain network 102. The environment 100 includescomputing systems 106, 108, and a network 110. In some examples, thenetwork 110 includes a local area network (LAN), wide area network(WAN), the Internet, or a combination thereof, and connects web sites,user devices (e.g., computing devices), and back-end systems. In someexamples, the network 110 can be accessed over a wired and/or a wirelesscommunications link. In some examples, the network 110 enablescommunication with, and within the consortium blockchain network 102. Ingeneral the network 110 represents one or more communication networks.In some cases, the computing systems 106, 108 can be nodes of a cloudcomputing system (not shown), or each of the computing systems 106, 108can be a separate cloud computing system including a number of computersinterconnected by a network and functioning as a distributed processingsystem.

In the depicted example, the computing systems 106, 108 can each includeany appropriate computing system that enables participation as a node inthe consortium blockchain network 102. Examples of computing systemsinclude, without limitation, a server, a desktop computer, a laptopcomputer, a tablet computing device, and a smartphone. In some examples,the computing systems 106, 108 host one or more computer-implementedservices for interacting with the consortium blockchain network 102. Forexample, the computing system 106 can host computer-implemented servicesof a first entity (e.g., user A), such as a transaction managementsystem that the first entity uses to manage its transactions with one ormore other entities (e.g., other users). The computing system 108 canhost computer-implemented services of a second entity (e.g., user B),such as a transaction management system that the second entity uses tomanage its transactions with one or more other entities (e.g., otherusers). In the example of FIG. 1, the consortium blockchain network 102is represented as a peer-to-peer network of nodes, and the computingsystems 106, 108 provide nodes of the first entity, and second entityrespectively, which participate in the consortium blockchain network102.

FIG. 2 is a diagram illustrating an example of an architecture 200 inaccordance with embodiments of the specification. The example conceptualarchitecture 200 includes participant systems 202, 204, 206 thatcorrespond to Participant A, Participant B, and Participant C,respectively. Each participant (e.g., user, enterprise) participates ina blockchain network 212 provided as a peer-to-peer network includingmultiple nodes 214, at least some of which immutably record informationin a blockchain 216. Although a single blockchain 216 is schematicallydepicted within the blockchain network 212, multiple copies of theblockchain 216 are provided, and are maintained across the blockchainnetwork 212, as described in further detail herein.

In the depicted example, each participant system 202, 204, 206 isprovided by, or on behalf of Participant A, Participant B, andParticipant C, respectively, and functions as a respective node 214within the blockchain network. As used herein, a node generally refersto an individual system (e.g., computer, server) that is connected tothe blockchain network 212, and enables a respective participant toparticipate in the blockchain network. In the example of FIG. 2, aparticipant corresponds to each node 214. It is contemplated, however,that a participant can operate multiple nodes 214 within the blockchainnetwork 212, and/or multiple participants can share a node 214. In someexamples, the participant systems 202, 204, 206 communicate with, orthrough the blockchain network 212 using a protocol (e.g., hypertexttransfer protocol secure (HTTPS)), and/or using remote procedure calls(RPCs).

Nodes 214 can have varying degrees of participation within theblockchain network 212. For example, some nodes 214 can participate inthe consensus process (e.g., as miner nodes that add blocks to theblockchain 216), while other nodes 214 do not participate in theconsensus process. As another example, some nodes 214 store a completecopy of the blockchain 216, while other nodes 214 only store copies ofportions of the blockchain 216. For example, data access privileges canlimit the blockchain data that a respective participant stores withinits respective system. In the example of FIG. 2, the participant systems202, 204, and 206 store respective, complete copies 216′, 216″, and216′″ of the blockchain 216.

A blockchain (e.g., the blockchain 216 of FIG. 2) is made up of a chainof blocks, each block storing data. Examples of data include transactiondata representative of a transaction between two or more participants.Transaction data is used as an example of data record stored in theblockchain. Examples of a transaction can include, without limitation,exchanges of something of value (e.g., assets, products, services,currency). In some embodiments, one or more operations executed in theledger system can be stored as transaction data in the blockchain. Forexample, the transaction data can include one or more operations ormanipulations of data stored in the block chain, information (e.g.,timestamp information) obtained from an external resource, or anyappropriate data can be stored in a blockchain (e.g., documents, images,videos, audio). The transaction data is immutably stored within theblockchain. That is, the transaction data cannot be changed.

Before storing in a block, the transaction data is hashed. Hashing is aprocess of transforming the transaction data (provided as string data)into a fixed-length hash value (also provided as string data). It is notpossible to un-hash the hash value to obtain the transaction data.Hashing ensures that even a slight change in the transaction dataresults in a completely different hash value. Further, and as notedabove, the hash value is of fixed length. That is, no matter the size ofthe transaction data the length of the hash value is fixed. Hashingincludes processing the transaction data through a hash function togenerate the hash value. An example of a hash function includes, withoutlimitation, the secure hash algorithm (SHA)-256, which outputs 256-bithash values.

Transaction data of multiple transactions are hashed and stored in ablock. For example, hash values of two transactions are provided, andare themselves hashed to provide another hash. This process is repeateduntil, for all transactions to be stored in a block, a single hash valueis provided. This hash value is referred to as a Merkle root hash, andis stored in a header of the block. A change in any of the transactionswill result in change in its hash value, and ultimately, a change in theMerkle root hash.

Blocks are added to the blockchain through a consensus protocol.Multiple nodes within the blockchain network participate in theconsensus protocol, and perform work to have a block added to theblockchain. Such nodes are referred to as consensus nodes. PBFT,introduced above, is used as a non-limiting example of a consensusprotocol. The consensus nodes execute the consensus protocol to addtransactions to the blockchain, and update the overall state of theblockchain network.

In further detail, the consensus node generates a block header, hashesall of the transactions in the block, and combines the hash value inpairs to generate further hash values until a single hash value isprovided for all transactions in the block (the Merkle root hash). Thishash is added to the block header. The consensus node also determinesthe hash value of the most recent block in the blockchain (i.e., thelast block added to the blockchain). The consensus node also adds anonce value, and a timestamp to the block header.

In general, PBFT provides a practical Byzantine state machinereplication that tolerates Byzantine faults (e.g., malfunctioning nodes,malicious nodes). This is achieved in PBFT by assuming that faults willoccur (e.g., assuming the existence of independent node failures, and/ormanipulated messages sent by consensus nodes). In PBFT, the consensusnodes are provided in a sequence that includes a primary consensus node,and backup consensus nodes. The primary consensus node is periodicallychanged, Transactions are added to the blockchain by all consensus nodeswithin the blockchain network reaching an agreement as to the worldstate of the blockchain network. In this process, messages aretransmitted between consensus nodes, and each consensus nodes provesthat a message is received from a specified peer node, and verifies thatthe message was not modified during transmission.

In PBFT, the consensus protocol is provided in multiple phases with allconsensus nodes beginning in the same state. To begin, a client sends arequest to the primary consensus node to invoke a service operation(e.g., execute a transaction within the blockchain network). In responseto receiving the request, the primary consensus node multicasts therequest to the backup consensus nodes. The backup consensus nodesexecute the request, and each sends a reply to the client. The clientwaits until a threshold number of replies are received. In someexamples, the client waits for f+1 replies to be received, where f isthe maximum number of faulty consensus nodes that can be toleratedwithin the blockchain network. The final result is that a sufficientnumber of consensus nodes come to an agreement on the order of therecord that is to be added to the blockchain, and the record is eitheraccepted, or rejected.

In some blockchain networks, cryptography is implemented to maintainprivacy of transactions. For example, if two nodes want to keep atransaction private, such that other nodes in the blockchain networkcannot discern details of the transaction, the nodes can encrypt thetransaction data. An example of cryptography includes, withoutlimitation, symmetric encryption, and asymmetric encryption. Symmetricencryption refers to an encryption process that uses a single key forboth encryption (generating ciphertext from plaintext), and decryption(generating plaintext from ciphertext). In symmetric encryption, thesame key is available to multiple nodes, so each node can en-/de-crypttransaction data.

Asymmetric encryption uses keys pairs that each include a private key,and a public key, the private key being known only to a respective node,and the public key being known to any or all other nodes in theblockchain network. A node can use the public key of another node toencrypt data, and the encrypted data can be decrypted using other node'sprivate key. For example, and referring again to FIG. 2, Participant Acan use Participant B's public key to encrypt data, and send theencrypted data to Participant B. Participant B can use its private keyto decrypt the encrypted data (ciphertext) and extract the original data(plaintext). Messages encrypted with a node's public key can only bedecrypted using the node's private key.

Asymmetric encryption is used to provide digital signatures, whichenables participants in a transaction to confirm other participants inthe transaction, as well as the validity of the transaction. Forexample, a node can digitally sign a message, and another node canconfirm that the message was sent by the node based on the digitalsignature of Participant A. Digital signatures can also be used toensure that messages are not tampered with in transit. For example, andagain referencing FIG. 2, Participant A is to send a message toParticipant B. Participant A generates a hash of the message, and then,using its private key, encrypts the hash to provide a digital signatureas the encrypted hash. Participant A appends the digital signature tothe message, and sends the message with digital signature to ParticipantB. Participant B decrypts the digital signature using the public key ofParticipant A, and extracts the hash. Participant B hashes the messageand compares the hashes. If the hashes are same, Participant B canconfirm that the message was indeed from Participant A, and was nottampered with.

FIG. 3 is a diagram illustrating an example of a blockchain-basedtrustable transaction system (such as a trading and financing system)300 in accordance with embodiments of this specification. Theblockchain-based trustable transaction system 300 implementsblockchain-based trustable trading, financing, and other data-exchangeservices using a blockchain network 320. The blockchain network 320 canbe the blockchain network 102 of FIG. 1 or the blockchain network 212 ofFIG. 2. For illustration purposes, a consortium blockchain network isdescribed as an example of the blockchain network 320, and theblockchain network 320 can also be a public or private blockchainnetwork. The blockchain network 320 can be composed of a plurality oftrustable nodes, e.g., nodes 321, 322, 324, 326, 328, for a selectedgroup of participants, e.g., entities 310, 330, 340, 350, 360. AlthoughFIG. 3 shows the nodes 321, 322, 324, 326, and 328 and their respectiveentities 310, 330, 340, 350, 360 with separated annotations, a personskilled in the art would understand that, in some embodiments, the nodes321, 322, 324, 326, and 328 can integrate one or more computing devicesof the their respective entities 310, 330, 340, 350, 360 as a singledevice or system, and vice versa. In some embodiments, the plurality oftrustable nodes can be consensus nodes that control consensus processesof the blockchain network 320. Each of the plurality of trustable nodecan be, for example, the node 106 or 108 of FIG. 1 or the node 214 ofFIG. 2. The blockchain network 320 can connect the participants, e.g.,trading platforms, buyer financial institutions, seller financialinstitutions, logistics providers or companies, customs offices, and/orsupplychain companies, together to build a trustable trade network inthe form of a blockchain alliance to provide guaranteed trade services.The blockchain technologies can make the trading and financing servicestraceable, decentralized, immutable, and transparent, with which allparticipants on the blockchain are able to build a better trust system.The trust system can allow values to be transferred efficiently.

The participants can include one or more financial institutions, e.g., abuyer bank 330 and a seller bank 340. A financial institution can be acompany engaged in the business of dealing with financial and monetarytransactions such as deposits, loans, investments, and currencyexchange. The financial institution can provide one or more financialservices, such as payments, loans, and currency exchanges to clients.The financial institution can include, for example, a bank, a trustcompany, an insurance company, a brokerage firm, or an investmentcompany. For illustration purposes, a bank is used as an example of afinancial institution in the present disclosure, and the describedtechniques can be applied to any other type of financial institutions.

In some embodiments, as illustrated in FIG. 3, the blockchain network320 includes a trustable trading platform node 321 corresponding to atrading platform 310. In some embodiments, the trustable tradingplatform node 321 and the trading platform 310 are communicativelyconnected. In some embodiments, the trustable trading platform node 321and the trading platform 310 can be implemented as a single computingdevice or system. In some embodiments, the trustable trading platformnode 321 and the trading platform 310 can be implemented as separatedcomputing device or systems. In some embodiments, a trustable tradingsystem can include the blockchain network 320 and the trading platform310.

In some embodiments, the blockchain network 320 includes a number oftrustable trading platform nodes for a number of different tradingplatforms. A trustable trading system can include the blockchain network320 and the number of different trading platform 310.

The trading platform 310 can provide trading services for tradingparties, e.g., buyers 302 and sellers 304. The trading parties can beindividuals or enterprises, e.g., SMEs. The sellers 304 can be suppliersfor providing products (including services). The trading platform 310can be an international or cross-border trading platform that providestrading services to buyers and sellers in different countries orregions. In some embodiments, each buyer has a buyer trading account onthe trading platform 310, and each seller has a seller trading accounton the trading platform 310.

A buyer 302 can use a buyer client device (e.g., a mobile device, alaptop, a desktop, or any other type of a computing device) to log inthe buyer trading account on the trading platform 310 with correspondingcredential information and get verified to trade with one or moresellers on the trading platform 310. A seller 304 can use a sellerclient device (e.g., a mobile device, a laptop, a desktop, or any othertype of a computing device) to log in the seller trading account on thetrading platform 310 with corresponding credential information and getverified to trade with one or more buyers on the trading platform 310.One or both parties of the buyer 302 and the seller 304 can draft anorder on the trading platform 310 and send to the other party forreview. The other party can amend or confirm the order, until anagreement between the buyer 302 and the seller 304 is reached. Afterboth of the buyer 302 and the seller 304 confirm the order, the tradingplatform 310 can upload order data of the order to the trading platformnode 321. The order data can include, for example, information of thebuyer 302, information of the seller 304, product information, and/orlogistics information (e.g., shipping information). The order data canalso include one or more order payments associated with one or morecorresponding payment conditions and corresponding payment time. In someembodiments, each order payment can have a corresponding paymentservice.

The trading platform 310 can upload the order data of the order to theblockchain network 320 through the corresponding trading platform node321. The trading platform node 321 can be configured to store the orderdata of the order on a blockchain of the blockchain network 320. Theblockchain can store associated information of the order, including theorder data, logistics data, payment data, customs data, supplychaindata, invoice data, or any data related to the order. The blockchain canbe accessed by each network node of the blockchain network. Theblockchain can be the blockchain 216 of FIG. 2. In some embodiments,each network node of the blockchain network can store a local copy ofthe blockchain in its own storage space. In some embodiments, each nodein the blockchain network 320 can receive corresponding order statusdata uploaded to the blockchain by a corresponding participant and storethe corresponding order status data on the blockchain. For example, theorder status data can include logistics data from a logistics provider350 uploaded via a corresponding logistics provider node 326,supplychain data from a supplychain service company, customs data from acustoms office 360 uploaded via a customs office node 328, bill oflanding data from the trading platform to the trading platform node, orpayment confirmation data from the buyer bank 330 uploaded via the buyerbank node 322 and/or payment reception data from the seller bank 340uploaded via the seller bank node 324. In such a way, the blockchainnetwork 320 can provide secure and convenient transactions, smart andinclusive finance, efficient and digital order management, which canmake data on the blockchain as the source of truth and providetransparency of the transaction history to users of the blockchain-basedtrustable trading and financing system 300. Through upstream anddownstream cross-validation, uploading source data to the blockchain andblockchain consensus mechanisms, the authenticity of the data on theblockchain can be guaranteed, so that the participants of the blockchainnetwork 320, e.g., the trading platform 310, the buyer bank 330, theseller bank 340, the logistics provider 350, and the customs office 360,can efficiently obtain real trade data from the blockchain and improvecollaboration efficiency.

In some embodiments, the blockchain network 320 can generate ablockchain trade invoice that can integrate real trade data on theblockchain to form a voucher. The voucher can be used as a basis forverification of trade authenticity by the participants, as well as atransaction voucher for buyers and sellers, and even as a paymentconfirmation. The blockchain trade invoice can be used to verify theauthenticity of trade, without complex offline processes andrequirements of a variety of certification materials and paperwork.

FIG. 8 illustrates an example of a blockchain trade invoice 800 inaccordance with embodiments of this specification. The blockchain tradeinvoice 800 can be generated by the blockchain network 320, e.g., thetrading platform node 321, based on order data of an order. The invoice800 can be updated, e.g., dynamically or in real time, based oncorresponding order status data of the order, e.g., customs informationor logistics information that can be updated with a state change of theorder. In some embodiments, the invoice 800 includes invoice information802, buyer/seller information 804, logistics information 806, productinformation 808, and summary information 810.

As an example illustrated in FIG. 8, the invoice information can includean invoice number (or an invoice identifier), an order number of theorder, an invoice date, and a buyer bank name. The buyer/sellerinformation 804 can include seller information (e.g., seller name,registration address, email, or other contact information) and buyerinformation (e.g., buyer name, registration address, email, or othercontact information). The logistics information 806 can include ashipping method (e.g., sea), a shipment term (e.g., free on board—FOB),a shipping cost. The logistics information 806 can also include acustoms status (e.g., pass) and customs number, which can be updatedwith customs data provided by the customs office 360. The logisticsinformation 806 can also include a shipping status (e.g., in transit),which can be updated with logistics data uploaded by the logisticsprovider 350. The production information 808 can include productpicture, product name, specification, note, number, and cost. Thesummary information 810 can include an order total amount, the shippingcost, a shipping insurance fee, and a total cost of the order.

Referring back to FIG. 3, the trading platform node 321 can generate asmart contract corresponding to the order on the blockchain. A smartcontract can include one or more computer-executable logics,instructions, scripts, or lines of codes that can be stored on theblockchain and automatically executed when one or more predeterminedconditions are met. As the smart contract is stored on the blockchain ofthe blockchain network 320, the smart contract is executed by thetrustable nodes of the blockchain network 320, and a result of theexecution of the smart contract occurs through a consensus process amongthe nodes. The smart contract can enforce an agreement such thatparticipants can be certain of an outcome without an intermediary'sinvolvement. As an example, a smart contract can include functions suchas “if/when . . . then . . . ” written in the form ofcomputer-executable codes. The smart contract can be deployed on theblockchain network, for example, by having a contract accountcorresponding to the smart contract on the blockchain, and the contractaccount has a specific address (also referred to as a smart contractaddress). The smart contract be invoked, for example, by a transactionon the blockchain transmitted from a network node, e.g., the node 321,322, 324, 326, or 328 of the blockchain network 320. The network nodecan execute the smart contract when predetermined conditions have beenmet and verified. In some embodiments, the smart contract can beexecuted independently on each node in the blockchain network.

In some embodiments, the trading platform node 321 can generate a smartcontract template that includes a plurality of logics or functions ofthe trustable trading services and deploy the smart contract template inthe blockchain network 320. For each order, a transaction correspondingto the order can be generated based on the order data of the order. Forexample, the trading platform node 321 can generate a transaction toinvoke or call one or more of the plurality of functions in the smartcontract template and use the order data as input to the one or more ofthe plurality of functions in the smart contract template. The tradingplatform node 321 can submit the transaction corresponding to the orderto the blockchain for storage and execution.

In some embodiments, the trading platform node 321 can generate arespective smart contract corresponding to each order and deploy therespective smart contract on the blockchain network 320. The respectivesmart contract are generated based on the order data of thecorresponding order and include functions of the trustable tradingservices for the corresponding order.

In some embodiments, in the former implementation, the transactioncorresponding to the order can be referred to as a smart contractcorresponding to the order as well since the transaction also includesinstructions or codes to invoke the functions defined in the smartcontract template. In some embodiments, in either of the exampleimplementations or other possible implementations, it is collectivelydescribed that a smart contract corresponding to an order can begenerated based on the order data of the order. A person skilled in theart would understand that the smart contract corresponding to the ordercan be implemented in different ways to include logics or functions torealize trustable trading services for the corresponding order. Forexample, the trading platform node 321 is configured to generate thesmart contract for the order from scratch, or the trading platform node321 is configured to generate the smart contract for the order from asmart contract template based on the order data, and the smart contracttemplate can include a plurality of functions for the trustable tradingservices. In the latter case, in generating the corresponding smartcontract for the order, the trading platform node 321 can be configuredto call one or more of the plurality of functions in the smart contracttemplate and use the order data as input to the one or more of theplurality of functions in the smart contract template to generate thesmart contract for the order as output.

In some embodiments, the smart contract for the order includes an orderstatus update function that automatically updates a status of the orderin response to determining the status of the order is changed based onthe order status data uploaded to the blockchain. The status of theorder can indicate, for example, products associated with the orderhaving been prepared or shipped by the seller, the products having beeninspected by the customs office 360, the products being transported bythe logistics provider 350, a bill of landing associated with the orderhaving been submitted by the seller 304 on the trading platform 310, thesubmitted bill of landing having been confirmed by the buyer 302 on thetrading platform 310, an invoice associated with the order having beengenerated by the blockchain network 320, the generated invoice havingbeen confirmed by the buyer 302, a consensus having been reached betweenthe buyer 302 and the seller 304 on the order, a payment for the orderhaving been made by the buyer bank 330, the payment for the order havingbeen received by the seller bank 340, the products having been receivedby the buyer 302, or any other order status information.

In some embodiments, the buyer 302 has a buyer financial account in thebuyer bank 330 that provides one or more financial services, e.g.,payment services, to the buyer. The buyer trading account on the tradingplatform 310 can include information of the buyer financial account,e.g., a name of the buyer bank 330, an account number, and a name of thebuyer. In some embodiments, the seller 304 has a seller financialaccount in a seller bank 340 that provides one or more financialservices, e.g., deposit services and/or financial loan services, to theseller 304. The seller trading account on the trading platform 310 caninclude information of the seller financial account, e.g., a name of theseller bank 340, an account number, and a name of the seller. In someembodiments, an order payment of an order between the buyer and theseller can be made between the buyer bank 330 and the seller bank 340without going through the trading platform 310. Thus, the tradingplatform 310 does not need to act as an escrow system between the buyerand the seller, which can mitigate a risk of the trading platform 310 asa guarantee. The buyer 302 and the seller 304 do not need to open theirown financing or monetary accounts in the trading platform 310 to makepayments. Instead, the buyer and the seller can exchange money or makepayment using their own bank accounts with their respective banks end toend without going through the trading platform, which can be morereliable and more efficient, e.g., can save their costs and efforts andcan reduce their concerns on the safety of their financial accounts.

In some embodiments, the buyer 302 and the seller 304 can be located orincorporated in different countries or regions so their trade isinternational trade or cross-border trade. Similarly, the buyer bank 330and the seller bank 340 can be located or incorporated in differentcountries or regions and subject to different financial regulations. Thepayment or other asset transfer between the buyer bank 330 and theseller bank 340 can be international or cross-border transactions. Forexample, relative to the trading platform 310, one of the buyer bank 330and the seller bank 340 is an offshore bank, and the other one of thebuyer bank 330 and the seller bank 340 is an onshore bank. The offshorebank and the onshore bank can deal with different currencies that areincompatible. The blockchain-based trustable trading and financingsystem 300 create a reliable and secured platform that can makeunaffiliated or incompatible entities compatible, e.g., enabling thebuyer bank 330 and the seller bank 340 to conduct transactions byintegrating the buyer bank node 322 for the buyer bank 330 and theseller bank node 324 for the seller bank 340 in the blockchain network320.

In some embodiments, an order payment between the buyer 302 and theseller 304 from the buyer bank 330 to the seller bank 340 is made by awire transfer. The wire transfer can be, for example, a Whale transferor a SWIFT transfer. In some embodiments, the order payment can be madein digital currencies between the buyer bank 330 and the seller bank340. In response to receiving a payment command, the buyer bank 330 cantransfer a digital value corresponding to the order payment to theseller bank 340, e.g., in the blockchain network 320 through the buyerbank node 322 and the seller bank node 324 or in any other blockchainnetwork.

As discussed with further details below, in some embodiments, the buyerbank 330 can provide a trustable automatic payment (AP) service to thebuyer 302 for trading on the trading platform 310. The trustable APservice is guaranteed by the buyer bank 330 that automatically makes apayment on behalf of the buyer 302 in response to that a paymentcondition for the payment specified in a corresponding smart contractdeployed on a corresponding blockchain of the blockchain network 320 ismet. According to the trustable AP service, the buyer bank 330 canautomatically make the payment without authorization or confirmation ofthe buyer 302. In such a way, the payment for the order can beguaranteed and can be made efficiently, effectively, and transparently.The trust between the buyer 302 and the seller 304 can be built orenhanced.

In some embodiments, the buyer 302 can select to use a correspondingtrustable AP service for an order on the trading platform 310 whendrafting the order or reviewing the order from the seller 304. After theorder is confirmed by the buyer 302 and the seller 304, the tradingplatform 310 transmits order data of the order to the trading platformnode 321 that stores the order data in a corresponding blockchain. Theorder data can include one or more order payments with one or morecorresponding payment conditions and data of the trustable AP servicefor the order. The data of the trustable AP service can include an orderpayment using the trustable AP service. The trading platform node 321can send a request to a computing device of the buyer bank 330 throughthe buyer bank node 322 to verify whether the buyer 302 or the buyerfinancial account is qualified for the trustable AP service for theorder payment. The buyer bank 330 can determine the qualification of thebuyer 302 or the buyer financial account based on, for example, a creditline of the buyer 302 or the buyer financial account. If the buyer bank330 determines that the buyer 302 or the buyer financial account isqualified for the trustable AP service for the order payment, thecomputing device of the buyer bank 330 can transmit verification data tothe buyer bank node 322 that stores the verification data on theblockchain for the order. Accordingly, the trading platform node 321 cansend a verification message corresponding to the verification data tothe trading platform 310. The trading platform 310 can confirm that thebuyer 302 can use the trustable AP service for the order based on theverification message and can then validate the order. The validation ofthe order can be uploaded to the blockchain by the trading platform 310via the trading platform node 321. The trading platform node 321 cangenerate a corresponding smart contract for the order. The correspondingsmart contract can be executed to automatically instruct the computingdevice of the buyer bank 330 to make the order payment to the selleraccording to the trustable AP service in response to determining thatthe corresponding payment condition for the order payment is met.

In some embodiments, having a trustable AP service can be a baserequirement or a default payment service for trading on the tradingplatform 310. After the buyer 302 logs in the buyer trading account onthe trading platform 310, the trading platform node 321 can communicatewith the buyer bank 330 to verify whether the buyer financial account ofthe buyer 302 or the buyer in the buyer bank 330 is qualified for thetrustable AP service on the trading platform 310. The trading platform310 can be configured to permit the buyer 302 to draft an order orreview an order the seller 304 prepared on the trading platform 310 inresponse to determining that the buyer 302 or the buyer financialaccount associated with the buyer trading account is qualified for thetrustable AP service. If the trading platform 310 determines that thebuyer 302 or the buyer financial account is not qualified for thetrustable AP service, the trading platform 310 can alert the buyer 302and refuse the buyer 302 to work on the order.

As discussed with further details below, in some embodiments, the buyerbank 330 can also provide a trustable undertaking (TU) service, e.g., atrustable bank payment undertaking (BPU) service. The TU payment serviceis guaranteed by the buyer bank 330 that automatically makes a paymentfor the buyer 302 based on a credit of the buyer 302 in the buyer bank330 in response to that a payment condition for the payment specified ina corresponding smart contract deployed on a corresponding blockchain ismet. According to the TU service, the buyer bank 330 guarantees to makethe payment no matter whether the buyer 302 has enough money or fund inthe buyer bank 330, which can greatly increase the certainty of thepayment and improve the trust between the buyer and the seller for theorder. For illustration purposes, the trustable BPU service is used asan example of the TU service in the present disclosure, and thedescribed techniques can be applied to any other type of trustableundertaking services.

In some embodiments, the trading platform 310 provides a user interface(e.g., a user interface 400 in FIG. 4), for example, to the buyer 302and/or the seller 304 for receiving user input of order data. In someembodiments, the user interface can include a selection to use acorresponding trustable BPU service for at least one payment of theorder with a corresponding payment condition and/or a correspondingpayment time. The payment time indicates, for example, a time periodafter the payment condition is met and before executing the trustableBPU service for the payment. As the trustable BPU service can beguaranteed by the buyer bank 330, the buyer 302 can negotiate thepayment time with the seller 304 based on the selection of the trustableBPU service for the payment of the order.

In some embodiments, if the trading platform 310 determines that thebuyer 302 selects to use the trustable BPU service for the orderconfirmed by the buyer 302 and the seller 304, the trading platform 310can request to verify whether the buyer bank 330 approves the buyer 302to use the trustable BPU service for the order through the tradingplatform node 321 and the buyer bank node 322. The buyer bank 330 candetermine the qualification of the buyer 302 or the buyer financialaccount, for example, based on a credit of the buyer 302 or the buyerfinancial account in the buyer bank 330. If the buyer bank 330determines that the buyer 302 or the buyer financial account isqualified for the trustable BPU service for the order payment, thecomputing device of the buyer bank 330 can transmit verification data tothe buyer bank node 322. The buyer bank node 322 can store theverification data for the order on the blockchain. Accordingly, thetrading platform node 321 can receive the verification data for theorder from the blockchain and send a verification message correspondingto the verification data to the trading platform 310. The tradingplatform 310 can confirm that the buyer 302 is qualified to use thetrustable BPU service for the order based on the verification messageand can then validate the order. The validation of the order can beuploaded by the trading platform 310 to the blockchain via the tradingplatform node 321. The trading platform node 321 can generate acorresponding smart contract for the order. The corresponding smartcontract can be executed to automatically instruct the computing deviceof the buyer bank 330 to make the order payment to the seller 304according to the trustable BPU service in response to determining thatthe corresponding payment condition for the order payment is met. Thebuyer bank 330 can make the payment commitment and guarantee to make theorder payment for the order to the seller 304. In such a way, thetrustable BPU service can convert the credit of the buyer bank 330 intothe buyer's credit in the buyer bank 330, which can increase the creditof the buyer 302 in the trade. Thus, the buyer 302 can use the trustableBPU service to negotiate better order terms, e.g., payment terms such asmore payment time, and/or lower initial payment amount. The trustableBPU service can capitalize the buyer's credit in the buyer bank 330, andcan use the buyer bank 330's guarantee to increase the buyer's credit inthe trade.

In some embodiments, a trustable undertaking certificate, e.g., atrustable BPU certificate, can be generated based on the order data ofthe order. The order data can include information of the buyer 302,information of the seller 304, product information, logisticsinformation, and at least one payment using the trustable BPU serviceand corresponding payment condition.

FIG. 9 illustrates an example trustable undertaking certificate, e.g., aBPU certificate 900 generated based on order data of a correspondingorder in accordance with embodiments of this specification. The BPUcertificate 900 includes BPU information 902, BPU data 904, bank accountinformation 906, shipping information 908, and product information 910.In some embodiments, the BPU information 902 includes a BPU certificatenumber (or an identifier of the BPU certificate), an order number, abuyer name, a seller name, and a buyer bank. The BPU data 904 caninclude a corresponding payment amount or BPU amount, an effective dateof the BPU, a total cost of the order, and a corresponding paymentcondition, e.g., making payment after 30 days when seller submits billof landing. The bank account information 906 can include information ofa buyer bank account (e.g., buyer name, account number, and buyer bankname) and information of a seller bank account (e.g., buyer name,account number, and seller bank name). The shipping information 908 caninclude a shipping method, e.g., sea, and a shipment term (or tradeterm), e.g., FOB. The product information 910 can include productpicture, name, specification, note, number, and cost. The BPUcertificate 900 can also include summary information 912 that includes ashipping cost, a shipping insurance rate, the total amount of the order,and a total cost of the order.

Referring back to FIG. 3, the trustable undertaking certificate can begenerated by the trading platform 310 or another trustable node in theblockchain network 320. The resulting trustable undertaking certificatecan be deposited, transferred, and traded on the blockchain like anasset. The trustable undertaking certificate can be used by the buyer302, the seller 304, or both.

In some embodiments, after an order is confirmed by the buyer 302 andthe seller 304, the trading platform 310 determines that the buyer 302selects a trustable BPU service for at least one payment for the order,and the trading platform 310 can generate a corresponding trustableundertaking certificate, e.g., a trustable BPU certificate (e.g., theBPU certificate 900), based on order data of the order. The tradingplatform 310 can submit the trustable undertaking certificate and theorder data to the trading platform node 321 to be stored on acorresponding blockchain of the blockchain network 320. The buyer 302can ask the buyer bank 330 to provide the trustable BPU service for thepayment of the order based on the trustable undertaking certificate. Thetrustable undertaking certificate can be a proof of authentication ofthe order. The buyer bank 330 can verify whether the buyer 302 isqualified for the trustable BPU service for the payment of the orderbased on a credit of the buyer 302 in the buyer bank 330.

In some embodiments, the trading platform node 321 can receive the orderdata of the order from the trading platform 310. In some embodiments,the order data of the order includes user input data indicating that thebuyer 302 selects the trustable BPU service for the payment of theorder. The trading platform node 321 can determine that the buyer 302selects the trustable BPU service for the payment of the order, and cangenerate a corresponding trustable undertaking certificate based on theorder data of the order. The trading platform node 321 can store thetrustable undertaking certificate on the blockchain, together with theorder data. The trading platform node 321 can provide the trustableundertaking certificate to the trading platform 310 that can forward toa client device of the buyer 302. The buyer 302 can ask the buyer bank330 to provide the BPU service for the payment of the order. The buyerbank 330 can get the trustable undertaking certificate from theblockchain through the buyer bank node 322 and verify the authenticationof the order and qualification of the buyer 302.

In some embodiments, as discussed above, after an order is confirmed bythe buyer 302 and the seller 304, the trading platform 310 determinesthat the buyer 302 selects a trustable BPU service for at least onepayment of the order, and the trading platform 310 can submit a requestto the buyer bank 330 through the trading platform node 321 and thebuyer bank node 322 to verify whether the buyer bank 330 will providethe trustable BPU service for the payment of the order to the buyer 302or to verify whether the buyer 302 is qualified for the trustable BPUservice for the payment of the order guaranteed by the buyer bank 330.If the buyer 302 is qualified for the trustable BPU service, the buyerbank 330 can submit verification data to the buyer bank node 322. Thebuyer bank node 322 stores the verification data on the blockchain. Thebuyer bank node 322 or the trading platform node 321 can generate acorresponding trustable undertaking certificate for the order based onthe verification data, e.g., in response to determining that the buyer302 is qualified for the trustable BPU service for the payment of theorder guaranteed by the buyer bank 330.

In some embodiments, with the trustable BPU service guaranteed by thebuyer bank 330, the seller 304 does not need to concern the payment fromthe buyer 302, and can have payment certainty for the order to ensurethe seller 304's funding liquidity and security. When the seller 304 hasfinancing needs, e.g., need for more money to manufacture products forthe order, the seller 304 can submit a financial request, e.g., for afinancial loan, to the seller bank 340. The seller bank 340 can verifywhether the seller 304 is qualified for the financial loan based on acredit of the seller 304 and/or on-chain trust, e.g., the trustableundertaking certificate generated on the blockchain. The seller bank 340can submit a verification request to the seller bank node 324 to checkcredible trade data on the blockchain and get the trustable undertakingcertificate, or the seller 304 can submit the financial request with thetrustable undertaking certificate to the seller bank 340. If the sellerbank 340 verifies that the seller 304 is qualified for the financialloan, the seller 304 can get the financial loan for its financial needs.The seller 304 can repay the financial loan, e.g., with the paymentreceived from the buyer bank 330 according to the trustable BPU servicefor the order.

The order can include one or more order payments corresponding to one ormore payment conditions. For example, the order can include an initialpayment (or prepayment) and a corresponding payment condition for theinitial payment and a remaining payment (or balance payment) and acorresponding payment condition for the remaining payment. In someembodiments, all the order payments of the order can be made accordingto a same payment service, e.g., a trustable automatic payment (AP)service or a trustable undertaking (TU) service such as a trustable BPUservice. In some embodiments, the order payments of the order can bemade according to a combination of the trustable AP service and thetrustable BPU service, e.g., different order payments can be made withdifferent payment services. The buyer 302 or the seller 304 can selectcorresponding payment services for different order payments on thetrading platform 310, e.g., through a user interface.

FIG. 4 illustrates an example of a user interface 400 provided by thetrading platform 310 of FIG. 3. The trading platform 310 can have adefault payment service, e.g., the trustable AP service. As noted above,the trading platform 310 can first verify whether a buyer is qualifiedfor the trustable AP service guaranteed by a buyer bank and present theuser interface 400 for the buyer to draft the order after a successfulverification.

The payment of the order can include one or more payments. A sum of theone or more payments is a total amount of the order. For example, apayment of the order can be divided into an initial payment and aremaining payment. A sum of the initial payment and the remainingpayment is a total amount of the order. In some examples, the initialpayment is 30% of the total amount of the order, and the remainingpayment is 70% of the total amount of the order. As illustrated in FIG.4, the user interface 400 includes an initial payment portion 410 forthe initial payment and a remaining payment portion 420 for theremaining payment. The buyer can set an initial payment amount 412,e.g., $3000. The label 414 shows that a payment condition forautomatically triggering the remaining payment is that a predeterminedtime has lapsed after the following condition is satisfied. The buyercan select a payment condition 416, e.g., order is validated, and set upa payment time 418, e.g., input a number of days or select a particulardate as a predetermined time (PDT). There is no selection for selectingthe trustable AP service in the initial payment portion 410, which meansthat the initial payment is made according to the default trustable APservice.

In the remaining payment portion 420, a remaining payment amount 422 isshown, e.g., automatically determined after the initial payment isselected. The label 424 shows that a payment condition for automaticallytriggering the remaining payment is that a predetermined time has lapsedafter the following condition is satisfied. The buyer can select apayment condition 426. A pop-up window 430 shows a list of paymentconditions, e.g., seller submits bill of landing, buyer confirms bill oflanding, system generates invoice such as the invoice 800 of FIG. 8,buyer confirms invoice, or buyer and seller reach consensus. Theselected payment condition can be highlighted, e.g., bolded. The buyercan also select a payment time 428, e.g., input a number of days orselect a particular date as a predetermined time (PDT). Different fromthe initial payment portion 410, the remaining payment portion 420includes a selection 429 for selecting BPU service. If the buyer doesnot select the BPU service, the remaining payment is assumed to be paidaccording to the default payment service, e.g., the trustable APservice. If the buyer selects the BPU service, the remaining payment isassumed to be made according to the BPU service. The buyer can negotiateextra payment time with the seller with the selection of the BPUservice. As noted above, a trustable BPU certificate, e.g., the BPUcertificate 900 of FIG. 9, can be generated accordingly. The tradingplatform can submit a verification request to verify whether the buyeris qualified for the BPU service for the order.

For illustration, the following figures FIGS. 5, 6, 7 are flowchartsillustrating examples of processes for implementing blockchain-basedtrustable trading services that can be executed in accordance withembodiments of this specification. Each process includes operationsrelated to a trustable automatic payment (AP) service and a trustablebank payment undertaking (BPU) service. The process can be implementedin an environment or system, e.g., the blockchain-based trustabletrading and financing system 300 of FIG. 3, that includes a blockchainnetwork, e.g., the blockchain network 320 of FIG. 3 and multipleparticipants including a trading platform, e.g., the trading platform310 of FIG. 3, a buyer bank, e.g., the buyer bank 330 of FIG. 3, aseller bank, e.g., the seller bank 340 of FIG. 3, a logistics provider,e.g., the logistics provider 350 of FIG. 3, and a customs office, e.g.,the customs office 360 of FIG. 3. The blockchain network can includemultiple trustable nodes corresponding to the multiple participants. Thetrading platform provides trustable trading services between a buyer,e.g., the buyer 302 of FIG. 3, and a seller, e.g., the seller 304 ofFIG. 3. The buyer bank provides financial services, e.g., paymentservices, for the buyer. The seller bank provides financial services,e.g., financial loans, deposits, for the seller. The trustable automaticpayment (AP) service can be a default payment service on the tradingplatform. The BPU service can be selected and verified.

Referring to FIG. 5, in a process 500, row 510 includes steps related tologistics that are performed by the customs office and the logisticsprovider; row 520 includes steps related to an information stream thatare performed on the trading platform, row 530 includes steps related toAP/BPU service, and row 540 includes steps related to a fund stream thatare performed by the buyer bank and the seller bank.

At 521, the process 500 starts. The buyer or the seller can log into abuyer trading account on the trading platform. The buyer trading accountcan include information of a buyer financial account in the buyer bank.In some embodiments, after the buyer logs into the buyer tradingaccount, the trading platform can submit a request to the blockchainnetwork to verify with the buyer bank whether the buyer is qualified forthe trustable AP service guaranteed by the buyer bank. The process 500proceeds if the trading platform receives a successful verification fromthe buyer bank.

At 522, an order is drafted on the trading platform. The tradingplatform can present a user interface, e.g., the user interface 400 ofFIG. 4. The buyer can select an initial payment amount or a remainingpayment amount, and corresponding payment conditions and payment timesfor the initial payment and the remaining payment. At 532, the buyerselects BPU service, e.g., in the user interface. After the order iscompleted, the buyer can send the order to the seller for review. Theseller can modify the order and send back the modified order to thebuyer for review.

At 523, the order is confirmed by the buyer and the seller on thetrading platform. At 533, after the order is confirmed, the tradingplatform submits order data 531 (or order information) to acorresponding trading platform node of the blockchain network, e.g., thenode 321 of FIG. 3. The order data 531 can include corresponding paymentconditions for one or more payments (such as initial payment andremaining payment) and BPU data for the BPU service. The BPU data canindicate that the BPU service is selected for the remaining payment.

At 534, the trading platform node stores the order data 531 on ablockchain of the blockchain network. The order data 531 includes aninitial payment condition for the initial payment, e.g., the paymentcondition 416 of FIG. 4, and a remaining payment condition for theremaining payment, e.g., the payment condition 426 of FIG. 4. Thetrading platform node can generate a blockchain trade invoice, e.g., theinvoice 800 of FIG. 8, based on the order data, and store the invoice onthe blockchain. The trading platform node can determine that the buyerselects the BPU service for the remaining payment for the order. In someembodiments, the trading platform node can generate a trustable BPUcertificate, e.g., the BPU certificate 900 of FIG. 9, based on the orderdata.

At 541, the trading platform node initials BPU application for theremaining payment by submitting a verification request to the buyer bankthrough a buyer bank node, e.g., the buyer bank node 322 of FIG. 3. At542, the buyer bank performs the BPU verification to determine whetherthe buyer is qualified for the BPU service for the remaining paymentbased on a credit of the buyer in the buyer bank, the invoice, and/orthe BPU certificate. If the buyer bank determines that the buyer isqualified for the BPU service for the remaining payment, the buyer bankcan submit corresponding verification data to the buyer bank node thatstores the verification data on the blockchain. The trading platformnode can transmit the verification data to the trading platform. At 535,the trading platform validates the order in response to receiving theverification data. The trading platform uploads validation data of theorder to the trading platform node of the blockchain network.

At 536, the trading platform node generates a smart contract 502 on theblockchain based on the order data. The smart contract 502 includes anautomatic function that automatically instructs the buyer bank to makethe initial payment for the order to the seller according to thetrustable AP service in response to determining that the initial paymentcondition for the initial payment is met and to make the remainingpayment for the order to the seller according to the trustable BPUservice in response to determining that the remaining payment conditionfor the remaining payment is met. The smart contract 502 includes anorder status update function that automatically updates a status of theorder in response to determining the status of the order is changedbased on the order status data uploaded to the blockchain from theparticipants, e.g., the trading platform, the buyer bank, the sellerbank, the customs office, and the logistics provider.

At 543, in response to determining that the initial payment conditionfor the initial payment is met, the smart contract automaticallytriggers an automatic payment command. The initial payment condition forthe initial payment can be that the order is validated by the tradingplatform. In some embodiments, the automatic payment command istriggered in response to determining that a predetermined time hasreached or a predetermined time period has lapsed after the initialpayment condition for the initial payment is met. The buyer financialinstitution node transmits the automatic payment command to a computingdevice of the buyer bank, and the automatic payment command instructsthe computing device of the buyer financial institution to make theinitial payment to the seller according to the trustable AP service.

At 544, the buyer bank makes the initial payment according to thetrustable AP service and submits payment data 545 to the buyer banknode. The payment data 545 confirms that the buyer bank has made theinitial payment to the seller. The buyer bank node stores the paymentdata 545 on the blockchain. At 546, the seller bank receives the initialpayment from the buyer bank and can submit payment reception data to theseller bank node that stores the payment reception data on theblockchain. The payment reception data confirms that the sellerfinancial account has received the initial payment. The trading platformcan be configured to receive the payment data (and/or the paymentreception data) from the blockchain through the trading platform nodeand feed back a payment status to the buyer and the seller based on thepayment data (and/or the payment reception data).

At 525, the seller ships products of the order. The seller can ship outthe products after step 524 that the order is validated on the tradingplatform, or after receiving the payment data and/or the paymentreception data. At 512, the customs office checks products and generatescustoms data 511. At 514, the logistics provider delivers the productsand generates logistics data 513. At 537, the customs data 511 issubmitted to the blockchain, e.g., from the customs office to thecustoms office node, and the logistics data 513 is submitted to theblockchain, e.g., from the logistics provider to the logistics providernode.

At 526, after the seller ships out the products, the seller submits abill of landing (B/L or BOL) to the trading platform, which can be theremaining payment condition for the remaining balance. The bill oflanding can be an electronic bill of landing (eBOL). The tradingplatform submits the B/L to the trading platform node for storing theB/L on the blockchain.

At 539, the remaining payment condition is reached, which can bedetected by the smart contract based on the order status data. Inresponse to determining that the remaining payment condition for theremaining payment is met, the smart contract triggers an automaticpayment command to instruct the buyer bank to make the remaining paymentfor the order to the seller. In some cases, if the buyer does not selectthe BPU service or the BPU application is rejected by the buyer bank, at538, the smart contract triggers an automatic AP command for the buyerbank to make the remaining payment according to the trustable APservice. In some cases, if the BPU application is approved by the buyerbank, at 547, the smart contract triggers an automatic BPU command toautomatically instruct the buyer bank to make the remaining payment forthe order to the seller according to the trustable BPU service.

At 548, the buyer bank makes the remaining payment according to the BPUservice and submits payment data 549 to the buyer bank node that storesthe payment data on the blockchain. At 546, the seller bank receives theremaining payment from the buyer bank according to the BPU service andcan submit payment reception data to the seller bank node that storesthe payment reception data on the blockchain.

At 550, the buyer bank can submit a payment success message to thetrading platform, e.g., through the buyer bank node and the tradingplatform node. Or the trading platform node can generate the paymentsuccess message based on the payment data and/or the payment receptiondata. At 527, the buyer confirms delivery of the products on the tradingplatform. Thus, the buyer receives the products and the seller receivesthe payment. The process 500 ends at 528.

Referring to FIG. 6, another process 600 for implementingblockchain-based trustable trading services is illustrated. In additionto the trustable AP service and the trustable BPU service shown in theprocess 500 of FIG. 5, the process 600 shows a generation of a trustableBPU certificate and a trustable BPU financing service.

The process 600 can include steps along row 630 related to an orderprocess, steps along row 602 related to BPU service, steps along row 604related to activities of the buyer bank, and steps along row 606 relatedto activities of the seller bank.

At 631, the process 600 starts. For example, a buyer logs into a buyertrading account in the trading platform. At 632, the buyer drafts anorder for trading with a seller on the trading platform. At 610, thebuyer selects a trustable BPU service for at least one payment such asthe remaining payment for the order. At 633, the trading platformvalidates the order, e.g., after the buyer and the seller confirmed theorder and the trading platform verifies that the buyer is qualified fora trustable AP service guaranteed by the buyer bank. In response todetermining that the initial payment condition is met with the orderbeing validated, the smart contract automatically triggers an automaticpayment demand to instruct the buyer bank to make the initial payment at634.

At 612, the trading platform initiates a BPU application to the buyerbank through the blockchain network, e.g., through the trading platformnode and the buyer bank node. At 614, the buyer bank verifies whetherthe buyer is qualified for the trustable BPU service for the payment forthe order based on a credit of the buyer and order data of the order.

At 616, the buyer bank determines that the buyer passes the BPUverification and submits verification data to the blockchain network,e.g., to the buyer bank node. The buyer bank node stores theverification data on a blockchain of the blockchain network.

At 618, the buyer bank node or the trading platform node generates atrustable BPU certificate, e.g., the BPU certificate 900 of FIG. 9. TheBPU certificate includes an amount of the payment that is guaranteed bythe buyer bank that automatically makes that automatically makes thepayment on behalf of the buyer in response to that a payment conditionspecified in a smart contract deployed on the blockchain is met. At 620,the seller uses the trustable BPU certificate to submit a financingrequest, e.g., a financing loan, to the seller bank 606. At 622, theseller bank approves the financing request of the seller.

At 635, the seller ships out products of the order. After the sellerships out products of the order, at 636, the seller submits an invoice,e.g., the invoice 800 of FIG. 8, on the trading platform, which can be aremaining payment condition for the remaining payment. The tradingplatform can submit the invoice to the trading platform node that storesthe invoice and associated order status data on the blockchain. At 637,the smart contract is executed to determine the remaining paymentcondition is reached and, at 624, automatically triggers an automaticcommand that instructs the buyer bank to make the remaining paymentaccording to the trustable BPU service for the remaining payment.

At 626, the buyer bank makes the remaining payment to the sellerfinancial account in the seller bank according to the trustable BPUservice for the remaining payment. At 628, the seller or the seller bankcan repay the financing, e.g., with the remaining payment received fromthe buyer bank. After making the remaining payment according to thetrustable BPU service, the buyer bank submits payment data to thetrading platform, e.g., through the buyer bank node and the tradingplatform node. The payment data confirms that the remaining payment hasbeen successfully made to the seller at 629. After the buyer confirmsdelivery of the products at 638, the process 600 is completed at 640.

Referring to FIG. 7, another process 700 for implementingblockchain-based trustable trading services is illustrated. Similar tothe process 500 of FIG. 5, the process 700 can apply both trustable APservice and trustable BPU service. The trustable AP service is the baseservice for the trading platform, and the BPU service is selectable forthe trading platform. As illustrated in FIG. 7, a base process 710 isillustrated by solid lines and includes steps shared by the AP serviceand the BPU service. A BPU-only process 750 is illustrated by dash linesand includes steps only related to the BPU service.

The process 700 can include steps along row 702 related to activities ofa buyer, steps along row 704 related to activities of the buyer bank,steps along row 706 related to activities of the seller, and steps alongrow 708 related to activities of the seller bank.

At 712, the buyer uses a client device to log into a buyer tradingaccount on the trading platform. At 714, the trading platform submits averification request to the buyer bank, e.g., through the tradingplatform node and the buyer bank node of the blockchain network. Theverification request requests the buyer bank to verify whether the buyeris authorized to use the trustable AP service and/or know your customer(KYC) service. At 716, the buyer bank performs the verification based ona credit of the buyer. At 720, the seller logins in a seller tradingaccount on the trading platform and gets verified with credentialinformation by the trading platform. In some embodiments, the sellertrading account includes information of a seller financing account inthe seller bank. At 722, the trading platform can verify whether theseller financial account is valid.

After the buyer is verified to have the authorization of using thetrustable AP service on the trading platform, at 718, the buyer ispermitted by the trading platform to draft an order for trading with theseller. At 724, the seller reviews and confirms the order. At 752, afterthe order is confirmed by the buyer and the seller, the trading platformcan determine that the buyer selects a trustable BPU service for aremaining payment of the order. The trading platform can submit a BPUapplication to the buyer bank through the trading platform node and thebuyer bank node. At 752, the buyer bank determines whether the buyer isqualified for the trustable BPU service based on a credit of the buyer.If the buyer is qualified, the BPU service is approved. The buyer bankcan submit verification data to the blockchain network, e.g., to thebuyer bank node. The buyer bank node stores the verification data on ablockchain of the blockchain network.

At 618, the buyer bank node or the trading platform node generates atrustable BPU certificate, e.g., the BPU certificate 900 of FIG. 9. TheBPU certificate includes an amount of the payment that is guaranteed bythe buyer bank that automatically makes that automatically makes thepayment on behalf of the buyer in response to that a payment conditionspecified in a smart contract deployed on the blockchain is met. At 620,the seller uses the trustable BPU certificate to submit a financingrequest, e.g., a financing loan, to the seller bank 606. At 622, theseller bank approves the financing request of the seller.

At 726, the buyer bank makes the initial payment according to thetrustable AP service, e.g., in response to receiving an automaticpayment command generated by a smart contract on the blockchain. Thesmart contract triggers the automatic payment command in response todetermining that an initial payment condition corresponding to theinitial payment is met.

At 728, the seller bank receives the initial payment from the buyerbank. If the seller bank and the buyer bank belong to offshore bank andonshore bank, the seller bank collect foreign exchange. After receivingthe initial payment, at 730, the seller ships products of the order. At732, the buyer confirms delivery of the products, which can be theremaining payment condition for the remaining payment. At 754 and 756,the remaining payment can be made by the trustable AP service or by thetrustable BPU service.

In some cases, if the buyer does not select the BPU service or the BPUapplication is rejected by the buyer bank, at 734, the smart contract onthe blockchain triggers an automatic AP command for the buyer bank tomake the remaining payment according to the trustable AP service. Insome cases, if the BPU application is approved by the buyer bank, at758, the smart contract triggers an automatic BPU command toautomatically instruct the buyer bank to make the remaining payment forthe order to the seller according to the trustable BPU service.

At 738, the seller bank receives the remaining payment from the buyerbank with foreign exchange collection. After the seller bank confirmsreception of the remaining payment, the process 700 ends.

FIGS. 10, 11, and 12 illustrate examples of processes for implementingblockchain-based trustable trading services that can be executed inaccordance with embodiments of this specification. Each processillustrates a flow of an order from start to end. The order is paid withan initial payment with a corresponding payment condition and aremaining payment with a corresponding payment condition. The initialpayment can be made by automatic initial payment (AIP) or manual initialpayment (MIP) if AIP fails. The remaining payment can be made byautomatic remaining payment (ARP) or manual remaining payment (MRP) ifARP fails. As illustrated in FIGS. 5-7, the AIP can be implemented by atrustable AP service, and the ARP can be implemented by a trustable APservice or a trustable BPU service.

The processes in FIGS. 10, 11, and 12 can be implemented in anenvironment or system, e.g., the blockchain-based trustable trading andfinancing system 300 of FIG. 3, that includes a blockchain network,e.g., the blockchain network 320 of FIG. 3 and multiple participantsincluding a trading platform, e.g., the trading platform 310 of FIG. 3,a buyer bank, e.g., the buyer bank 330 of FIG. 3, a seller bank, e.g.,the seller bank 340 of FIG. 3, a logistics provider, e.g., the logisticsprovider 350 of FIG. 3, and a customs office, e.g., the customs office360 of FIG. 3. The blockchain network can include multiple trustablenodes corresponding to the multiple participants. The trading platformprovides trustable trading services between a buyer, e.g., the buyer 302of FIG. 3, and a seller, e.g., the seller 304 of FIG. 3. The buyer bankprovides financial services, e.g., payment services, for the buyer. Theseller bank provides financial services, e.g., financial loans,deposits, for the seller. In some embodiments, a trustable tradingsystem includes the blockchain network 320 that can be coupled todifferent trading platforms. In some embodiments, the trustable tradingsystem includes the blockchain network 320 and the trading platform.

FIG. 10 is a flowchart illustrating an example of a process 1000 forimplementing blockchain-based trustable trading services with variouspayment conditions that can be executed in accordance with embodimentsof this specification.

At 1002, the process 1000 starts. For example, the buyer can use a buyerclient device to log in a buyer trading account on the trading system.At 1004, the buyer drafts the order, e.g., similar to step 522 of FIG.5, 632 of FIG. 6, or 718 of FIG. 7. The order can include order termsand payment conditions. At 1006, after the buyer completes the order,the trading platform is waiting for the seller to conform the order. At1008, the trading platform sends a notify message as a seller event to aseller client device of the seller to confirm the order.

In some cases, if the seller cancels the order at 1016, the order isclosed at 1018. In some cases, if the trading platform has not receivedthe seller's confirmation after a predetermined time period, the orderis cancelled at 1016 and closed at 1018. In some cases, the sellermodifies the order at 1010 and sends to the trading system. At 1012, thetrading platform is waiting for the buyer to confirm the modified order.At 1014, the trading platform sends a notify message as a buyer event tothe buyer client device of the buyer to accept modification. In somecases, if the buyer cancels the modified order by the seller at 1016,the order is closed at 1018. In some cases, if the buyer confirms themodified order at 1020, it indicates that the modified order isconfirmed by both the buyer and the seller. If the seller confirms theorder the buyer drafted at 1022, it indicates that the order isconfirmed by both the buyer and the seller. The trading platform recordsthe confirmed order at 1024. The trading platform can submit order dataof the confirmed order on a blockchain of the blockchain network, e.g.,similar to step 533 of FIG. 5.

A smart contract for the order can be generated on the blockchain basedon the order data. The smart contract can include an automatic functionthat automatically instructs the buyer bank to make an order payment forthe order to the seller according to a payment service in response todetermining that a payment condition for the order payment is met. Thesmart contract can also include an order status update function thatautomatically updates a status of the order in response to determining astatus of the order is changed based on order status data uploaded tothe blockchain.

At 1026, the seller (or the seller bank) is waiting for the initialpayment from the buyer (or the buyer bank). At 1028, the seller can senda notify message as a buyer event to the buyer client device of thebuyer to make the automatic initial payment (AIP). In some cases, thebuyer bank node can execute the smart contract to automatically instructthe buyer bank to make the initial payment to the seller (or the sellerbank) according to AIP in response to determining that a paymentcondition deployed on the smart contract is met. At 1030, if the AIPfails, the order can be cancelled at 1034 and the order is closed at1018, or the trading platform sends a notify message as a buyer event tothe buyer client device of the buyer make the payment according to theMIP service at 1032. In some cases, the buyer can request to modify theorder term or order condition, the seller can modify, and the buyer canagree again at 1036.

If the AIP succeeds or if AIP fails but MIP succeeds at 1038, thetrading system is waiting for the seller to ship products of the orderat 1040. The trading system can send a notify message as a seller eventto the seller client device of the seller to ship at 1042. At 1044, theproducts are shipped out by the seller, and logistics information andcustoms information can be uploaded to the blockchain by correspondinglogistics provider and customs office.

At 1046, the trading system records shipment data on the blockchain andsends a notify message 1048 as a buyer event to the buyer client devicethat shipment is started. At 1050, the logistics provider can submitshipment complete data to the blockchain or the customs office cansubmit customs data showing that the products pass the inspection to theblockchain.

There can be a number of different payment conditions for the remainingpayment. If the payment condition is an invoice type and the buyer needs to confirm at 1056, the trading system is waiting for the buyer toconfirm the invoice at 1058. The trading system can send a notifymessage 1060 as a buyer event to the buyer client device to confirm theinvoice. After the buyer confirms the invoice at 1062, the tradingsystem waits for the buyer bank to make the remaining payment at 1054,e.g., by executing the smart contract to automatically instruct thebuyer bank to make the remaining payment according to the ARP service.

In some embodiments, the payment condition for the remaining payment iselectronic bill of landing (eBOL) type (1064). The trading system iswaiting for the seller to upload the eBOL at 1066 and can send a notifymessage 1068 to the seller client device of the seller. If the paymentcondition is that the seller submits the eBOL without the buyer'sconfirmation (1070), the process 1000 proceeds to step 1054. If thepayment condition is that the eBOL is submitted with the buyer'sconfirmation (1072), the trading system waits for the buyer to confirmthe eBOL at 1074 and sends a notify message 1076 to ask the buyer toconfirm the eBOL. After the buyer confirms the eBOL at 1078, the process1000 proceeds to step 1054.

In some embodiments, the payment condition for the remaining conditionis an invoice type without the buyer's confirmation (1052), and theprocess 1000 proceeds directly from 1050 to 1054, that is, waiting forthe remaining payment.

The trading system can send a notify message 1080 as a buyer event tothe buyer bank or the client device of the buyer to make the remainingpayment according to the ARP. If the ARP fails at 1082, the tradingsystem can send a notify message 1084 to the buyer bank or the buyerclient device of the buyer to make the remaining payment according tothe MRP. If the ARP succeeds or if the ARP failed but MRP succeeds at1086, the trading system is waiting for delivery confirmation at 1088.The trading system can send a notify message 1090 as a buyer event tothe buyer client device to confirm delivery of the products. After thebuyer confirms delivery at 1092, the order is completed at 1094.

FIG. 11 is a flowchart illustrating an example of a process 1100 forimplementing blockchain-based trustable trading services with aconsensus payment condition that can be executed in accordance withembodiments of this specification.

At 1102, the process 1100 starts. At 1104, the buyer drafts an order onthe trading platform. After the order is completed, the trading systemis waiting for the seller to confirm the order at 1106 and sends anotify message to ask the seller to confirm the order at 1108. If theseller confirms the order at 1122, it indicates that the order isconfirmed by both the buyer and the seller, and the order is recorded at1124.

If the seller cancels the order at 1116, the order is closed at 1118. Ifthe seller modifies the order at 1110, the trading platform is waitingfor the buyer to confirm the modified order at 1112 and can send anotify message 1114 to ask the buyer to accept modification. If thebuyer cancels the modified order at 1116, the order is closed at 1118.If the buyer confirms the modified order at 1120, it indicates that themodified order is confirmed by both the buyer and the seller, and themodified order is recorded at 1124.

The initial payment condition for the initial payment is recording theorder. After the order is recorded, e.g., on a blockchain of theblockchain network, the trading system is waiting for the initialpayment at 1126. If the AIP fails at 1130, the initial payment can bemodified at 1128, and the trading system can notify the buyer to makethe initial payment according to the MIP. If the AIP succeeds or if theAIP failed but the MIP succeeds at 1132, the trading system is waitingfor the remaining payment by the buyer bank or the buyer at 1134.

If the payment condition is that the buyer and the seller reachconsensus (1136) and if either ARP or MRP succeeds, the trading systemis waiting for the seller to ship products at 1138. At 1144, theproducts are being shipped, and logistics information and customsinformation can be uploaded by the logistics provider and the customsoffice to the trading system. The trading system can determine theshipment started based on the order status data at 1146. After theshipment is completed and passes the customs at 1148, the trading systemis waiting for delivery confirmation at 1150. After the trading systemreceives delivery confirmation from the buyer at 1152, the order iscompleted at 1154.

FIG. 12 show a diagram 1200 illustrating steps in the processes of FIG.10 and FIG. 11 in accordance with embodiments of this specification.Block 1210 shows different icons representing different meaning. Icon1212 represents an initial condition, icon 1214 represents anoff-blockchain condition, icon 1216 represents on-blockchain condition,icon 1218 represents end condition, icon 1220 represents a notifymessage as a buyer event, and icon 1222 represents a notify message as aseller event.

Block 1230 illustrates how to modify condition. At 1232, the tradingsystem allows a modify condition. At 1234, the buyer submits a modifyrequest, and the trading system is waiting for the seller to modify at1236 and sends a notify message to the seller to modify at 1238. Ifthere is no need for this condition, the trading system can still showthe previous condition. The seller modifies at 1240 and the tradingsystem is waiting for the buyer to confirm the modified order at 1242.The trading system sends a notify message as a buyer event to ask thebuyer to accept modification at 1248. If the buyer refuses to confirmthe modified order at 1244, the process goes back to step 1232. If thebuyer confirms the modified order at 1246, the process goes back to step1232.

Block 1250 illustrates a state change for notify for payment success. At1252, the payment state is at state 1. After the payment is successfullymade under AIP or MIP for the initial payment, or ARP or MRP for theremaining payment at 1256, the payment state is at state 2 (1254). Thetrading system sends a notify message 1258 as a seller event to notifythe seller about the payment success and sends a notify message 1260 asa buyer event to notify the buyer about the payment success.

FIG. 13A is a flowchart illustrating an example of a process 1300 formanaging blockchain-based trustable transaction services that can beexecuted by a blockchain-based trustable trading and financing system(e.g., the blockchain-based trustable trading and financing system 300of FIG. 3) in accordance with embodiments of this specification. Theblockchain-based trustable trading and financing system can include ablockchain network. The blockchain network can be a public, private, orconsortium blockchain network. In some embodiments, the blockchainnetwork can be the blockchain network 102 of FIG. 1, the blockchainnetwork 212 of FIG. 2, or the blockchain network 320 of FIG. 3. Theblockchain network can be composed of a plurality of trustable nodes.Each trustable node can correspond to a respective participant of tradein the blockchain-based trustable trading and financing system. In someembodiments, one or more of the steps of the process 1300 can beperformed by a trustable network node of the blockchain network (e.g.,the trading platform node 321, the buyer bank node 322, or the sellerbank node 324). In some embodiments, one or more of the steps of theprocess 1300 can be performed by a computing device connected to thetrustable network node of the blockchain network (e.g., the tradingplatform 310, a computing device of the buyer bank 330, or a computingdevice of the seller bank node 324). In some embodiments, one or more ofthe steps of the process 1300 can be performed by a combination or anintegration of a trustable network node of the blockchain network (e.g.,the trading platform node 321) and the computing device connected to thetrustable network node of the blockchain network (e.g., the tradingplatform 310). In some embodiments, one or more of the steps of theprocess 1300 can be performed according to the techniques described withrespect to the processes 500, 600, 700, 1000, 1100, and/or 1200.

At 1302, order data of an order between a buyer (e.g., the buyer 302 ofFIG. 3) and a seller (e.g., the seller 304 of FIG. 3) is stored on ablockchain of the blockchain network for the order. The order dataincludes one or more payment conditions for the order. The order datacan be stored by a trustable trading platform node, e.g., the node 321of FIG. 3, corresponding to a trading platform, e.g., the trade platform310 of FIG. 3. The trading platform is configured to provideblockchain-based trustable trading services between the buyer and theseller. The order data can be stored on the blockchain after the orderis confirmed by the buyer and the seller on the trading platform.

At 1304, the buyer is verified to have a trustable automatic payment(AP) service guaranteed by a buyer financial institution, e.g., thebuyer bank 330 of FIG. 3. The trustable AP service is guaranteed by thebuyer financial institution that automatically makes a payment on behalfof the buyer in response to that a condition specified in a smartcontract deployed on a blockchain of the blockchain network is met. Eachorder can correspond to a corresponding smart contract. Each order canhave one or more order payments with one or more corresponding paymentconditions. Each order can correspond to a corresponding blockchain ofthe blockchain network.

Having the trustable AP service can be a base requirement for using thetrading platform. After the buyer logs in a buyer trading account on thetrading platform, the trading platform node can communicate with a buyerfinancial institution node, e.g., the node 322 of FIG. 3, correspondingto the buyer financial institution to verify whether a buyer financialaccount of the buyer in the buyer financial institution is qualified forthe trustable AP service on the trading platform. The buyer financialinstitution node can communicate with a computing device of the buyerfinancial institution to verify that the buyer has the trustableautomatic payment service guaranteed by the buyer financial institution.The buyer trading account can include information of the buyer financialaccount, e.g., an account number, a buyer name, and a name of the buyerfinancial institution. The trading platform can be configured to permitthe buyer to draft an order or review an order the seller prepared onthe trading platform in response to determining that the buyer financialaccount is qualified for the trustable AP service.

The seller also has a seller trading account on the trading platform anda seller financial account in a seller financial institution. Theblockchain network can include a seller financial institution nodecorresponding to the seller financial institution. The buyer financialinstitution can make a payment for the buyer to the seller financialaccount in the seller financial institution. In some embodiments, one ofthe buyer financial institution and the seller financial institution isan offshore entity, and the other one of the buyer financial institutionand the seller financial institution is an onshore entity. The offshoreentity and the onshore entity are subject to different financialregulations, and the buyer financial institution node corresponding tothe buyer financial institution and the seller financial institutionnode corresponding to the seller financial institution belong to thesame blockchain network of the plurality of trustable nodes.

At 1306, a corresponding smart contract for the order is generated onthe blockchain based on the order data. The corresponding smart contractcan include an automatic function that automatically instructs the buyerfinancial institution to make an order payment for the order to theseller according to the trustable AP service in response to determiningthat a corresponding payment condition for the order payment is met. Insome embodiments, the trading platform node is configured to generatethe corresponding smart contract for the order from a smart contracttemplate based on the order data, the smart contract template includinga plurality of functions for the trustable trading services. Ingenerating the corresponding smart contract for the order, the tradingplatform node can be configured to call one or more of the plurality offunctions in the smart contract template and use the order data as inputto the one or more of the plurality of functions in the smart contracttemplate.

At 1308, order status data of the order uploaded to the blockchain isreceived. Each node in the blockchain network can receive correspondingorder status data uploaded by a corresponding participant. The orderstatus data can include at least one of logistics data from a logisticsprovider such as the logistics provider 350 of FIG. 3 to a logisticsprovider node such as the node 326 of FIG. 3, supplychain data from asupplychain service company, customs data from a customs office such asthe customs office 360 of FIG. 3 to a customs office node such as thenode 328 of FIG. 3, bill of landing data from the trading platform tothe trading platform node, or payment data from the buyer financialinstitution to the buyer financial institution node and/or payment datafrom the seller financial institution to the seller financialinstitution node.

The corresponding smart contract can include an order status updatefunction that automatically updates a status of the order in response todetermining the status of the order is changed based on the order statusdata uploaded to the corresponding blockchain. The status of the ordercan indicate at least one of products associated with the order havingbeen prepared or shipped by the seller, the products having beeninspected by the customs office, the products being transported by thelogistics provider, a bill of landing associated with the order havingbeen submitted by the seller on the trading platform, the submitted billof landing having been confirmed by the buyer on the trading platform,an invoice associated with the order having been generated by theblockchain network, the generated invoice having been confirmed by thebuyer, a consensus having been reached between the buyer and the selleron the order, the automatic payment having been made by the buyerfinancial institution, the automatic payment having been received by theseller financial institution, or the products having been received bythe buyer.

At 1310, the corresponding smart contract is executed to automaticallyinstruct the computing device of the buyer financial institution to makethe order payment to the seller according to the trustable AP service inresponse to determining that the corresponding payment condition for theorder payment is met based on the order status data. In response todetermining that the corresponding payment condition for the orderpayment is met, the corresponding smart contract can automaticallygenerate or trigger an automatic payment command. The buyer financialinstitution node can transmit the automatic payment command to thecomputing device of the buyer financial institution, the automaticpayment command instructing the computing device of the buyer financialinstitution to make the order payment to the seller according to thetrustable AP service. In some embodiments, the corresponding smartcontract generates the automatic payment command in response todetermining that a predetermined time has reached or a predeterminedtime period has lapsed after the corresponding payment condition for theorder payment is met.

The buyer financial institution node can be configured to execute thecorresponding smart contract to automatically instruct the computingdevice of the buyer financial institution to make the order paymentdirectly to the seller financial account in the seller financialinstitution, without going through the trading platform, in response todetermining that the corresponding payment condition for the orderpayment is met.

In some embodiments, the one or more payment conditions include a firstpayment condition for a first payment for the order and a second paymentcondition for a second payment for the order. The buyer financialinstitution node can be configured to: execute the corresponding smartcontract to automatically instruct the computing device of the buyerfinancial institution to make the first payment to the seller inresponse to determining that the first condition for the first paymentis met, and execute the corresponding smart contract to automaticallyinstruct the computing device of the buyer financial institution to makethe second payment to the seller in response to determining that thesecond condition for the second payment is met.

In some embodiments, the first payment is an initial payment of theorder, and the first payment condition includes the order having beenvalidated on the trading platform. The second payment is a remainingpayment of the order, and the second payment condition can include atleast one of: a bill of landing associated with the order having beensubmitted by the seller on the trading platform, the submitted bill oflanding having been confirmed by the buyer on the trading platform, aninvoice associated with the order having been generated by theblockchain network, the generated invoice having been confirmed by thebuyer, or a consensus having been reached between the buyer and theseller on the order.

In some embodiments, the order payment can be made by wire transferbetween the buyer financial institution and the seller financialinstitution. The wire transfer can be a Whale transfer or a SWIFTtransfer. In some embodiments, the order payment can be made in digitalcurrencies. In response to receiving the automatic payment command, thebuyer financial institution can transfer a digital value correspondingto the order payment to the seller financial institution, e.g., in theblockchain network through the buyer financial institution node and theseller financial institution node or in any other blockchain network.

The buyer financial institution node can be configured to receive orderpayment data confirming that the buyer financial institution has madethe order payment to the seller and store the order payment data on thecorresponding blockchain. The seller financial institution node can beconfigured to store payment reception data on the correspondingblockchain, the payment reception data confirming that the order paymenthas been received by the seller financial account in the sellerfinancial institution from the buyer financial institution. The tradingplatform can be configured to receive the order payment data from thecorresponding blockchain through the trading platform node and feed backa payment status to the buyer and the seller based on the order paymentdata.

FIG. 13B is a flowchart illustrating an example of a process 1330 formanaging blockchain-based trustable transaction services that can beexecuted by a blockchain-based trustable trading and financing system(e.g., the blockchain-based trustable trading and financing system 300of FIG. 3) in accordance with embodiments of this specification. Theblockchain-based trustable trading and financing system can include ablockchain network. The blockchain network can be a public, private, orconsortium blockchain network. In some embodiments, the blockchainnetwork can be the blockchain network 102 of FIG. 1, the blockchainnetwork 212 of FIG. 2, or the blockchain network 320 of FIG. 3. Theblockchain network can be composed of a plurality of trustable nodes.Each trustable node can correspond to a respective participant of tradein the blockchain-based trustable trading and financing system. In someembodiments, one or more of the steps of the process 1330 can beperformed by a trustable network node of the blockchain network (e.g.,the trading platform node 321, the buyer bank node 322, or the sellerbank node 324). In some embodiments, one or more of the steps of theprocess 1330 can be performed by a computing device connected to thetrustable network node of the blockchain network (e.g., the tradingplatform 310, a computing device of the buyer bank 330, or a computingdevice of the seller bank node 324). In some embodiments, one or more ofthe steps of the process 1330 can be performed by a combination or anintegration of a trustable network node of the blockchain network (e.g.,the trading platform node 321) and the computing device connected to thetrustable network node of the blockchain network (e.g., the tradingplatform 310). In some embodiments, one or more of the steps of theprocess 1330 can be performed according to the techniques described withrespect to the processes 500, 600, 700, 1000, 1100, and/or 1200.

At 1332, order data of an order between a buyer and a seller is storedon a blockchain of the blockchain network for the order. The order dataincludes one or more payment conditions for the order and data of atrustable undertaking (TU) service for the order. The order data can bestored by a trustable trading platform node corresponding to a tradingplatform. The trading platform is configured to provide blockchain-basedtrustable trading services between the buyer and the seller. The orderdata can be stored on the blockchain after the order is confirmed by thebuyer and the seller on the trading platform.

At 1334, the buyer is verified to have the trustable undertaking (TU)service for the order guaranteed by a buyer financial institution thatautomatically makes a payment of the order for the buyer to the sellerbased on a credit of the buyer in the buyer financial institution inresponse to that a condition specified in a smart contract deployed onthe blockchain is met.

In some embodiments, the trading platform node is configured to:determine, based on the TU data, that the buyer selects to use the TUservice for the order on the trading platform, and transmit a request toa computing device of the buyer financial institution through the buyerfinancial institution node, the request requesting the buy financialinstitution to verify whether the buyer is qualified for the TU servicefor the order guaranteed by the buyer financial institution.

In some embodiments, the trading platform is configured to provide auser interface for receiving user input of the order data, and the userinterface includes a selection to use the corresponding TU service forthe order.

In some embodiments, the trading platform node is configured to transmitthe request after storing the order data of the order on the blockchain.

In some embodiments, the blockchain network includes a buyer financialinstitution node corresponding to the buyer financial institution. Thebuyer financial institution node is configured to: receive verificationdata from the computing device of the buyer financial institution, theverification data confirming that the buyer has the TU service for theorder guaranteed by the buyer financial institution, and store theverification data on the corresponding blockchain.

In some embodiments, the trading platform is configured to: determine,based on the verification data stored on the blockchain, that the buyerhas the TU service for the order guaranteed by the buyer financialinstitution, and validate the order after determining that the buyer hasthe TU service for the order guaranteed by the buyer financialinstitution.

In some embodiments, the corresponding payment condition for the orderpayment is determined based on the TU service for the order.

At 1336, the smart contract for the order is generated based on theorder data of the order, and the smart contract includes an automaticfunction that automatically instructs the buyer financial institution tomake an order payment for the order to the seller according to the TUservice for the order in response to determining that a correspondingpayment condition for the order payment is met. In some embodiments, thetrading platform node is configured to generate the corresponding smartcontract for the order from a smart contract template based on the orderdata, the smart contract template including a plurality of functions forthe trustable trading services. In generating the corresponding smartcontract for the order, the trading platform node can be configured tocall one or more of the plurality of functions in the smart contracttemplate and use the order data as input to the one or more of theplurality of functions in the smart contract template.

At 1338, order status data of the order uploaded to the blockchain isreceived. In some embodiments, the smart contract further includes anorder status update function that automatically updates a status of theorder in response to determining the status of the order is changedbased on order status data uploaded to the corresponding blockchain.

In some embodiments, the status of the order indicates at least one of:products associated with the order having been prepared or shipped bythe seller, the products having been inspected by a customs office, theproducts being transported by at least one logistics provider, a bill oflanding associated with the order having been submitted by the seller onthe trading platform, the submitted bill of landing having beenconfirmed by the buyer on the trading platform, an invoice associatedwith the order having been generated by the blockchain network, thegenerated invoice having been confirmed by the buyer, a consensus havingbeen reached between the buyer and the seller on the order, theautomatic payment having been made by the buyer financial institution,the automatic payment having been received by the seller, or theproducts having been received by the buyer.

In some embodiments, the blockchain networks of the plurality oftrustable nodes further includes at least one of: a customs office nodecorresponding to the customs office, the order status data includingcustom data uploaded to the corresponding blockchain by the customsoffice node, or a logistic provider node corresponding to the at leastone logistics provider, the order status data including logistic datauploaded to the corresponding blockchain by the logistic provide node.

In some embodiments, the order status data includes at least one oflogistics data, supplychain data, customs data, bill of landing data, orpayment data.

At 1340, the smart contract is executed to automatically instruct acomputing device of the buyer financial institution to make the orderpayment to the seller according to the TU in response to determiningthat the corresponding payment condition for the order payment is metbased on the order status data.

In some embodiments, the blockchain network includes a buyer financialinstitution node corresponding to the buyer financial institution. Thebuyer financial institution node is configured to: receive order paymentdata confirming that the buyer financial institution has successfullymade the order payment to the seller according to the TU service for theorder, and store the order payment data on the blockchain.

In some embodiments, the blockchain network includes a seller financialinstitution node corresponding to a seller financial institution. Theseller has a seller financial account in the seller financialinstitution, and the seller financial institution node is configured tostore payment reception data on the corresponding blockchain, thepayment reception data confirming that the order payment for the orderhas been received by the seller financial account in the sellerfinancial institution from the buyer financial institution.

In some embodiments, the buyer financial institution node is configuredto execute the smart contract to automatically instruct the computingdevice of the buyer financial institution to make the order payment tothe seller according to the TU service for the order in response todetermining that a predetermined time has reached or a predeterminedtime period has lapsed after the corresponding payment condition for theorder payment is met.

In some embodiments, the predetermined time or the predetermined timeperiod is determined based on the corresponding TU service for theorder.

In some embodiments, the one or more payment conditions includes a firstpayment condition for a first payment for the order and a second paymentcondition for a second payment for the order. The second payment is theorder payment made according to the TU service for the order, and thesecond payment condition includes the corresponding payment condition.The buyer financial institution node is configured to execute the smartcontract to automatically instruct the computing device of the buyerfinancial institution to make the second payment to the seller accordingto the TU service for the order in response to determining that thesecond payment condition for the second payment is met.

In some embodiments, the buyer financial institution node is configuredto: execute the smart contract to automatically instruct the computingdevice of the buyer financial institution to make the first payment tothe seller according to a trustable automatic payment service for thebuyer provided by the buyer financial institution in response todetermining that the first payment condition for the first payment ismet.

In some embodiments, the trading platform node is configured to: afterthe buyer logs in a buyer trading account on the trading platform,communicate with the computing device of the buyer financial institutionthrough the buyer financial institution node to verify whether a buyerfinancial account of the buyer in the buyer financial institution isqualified for the trustable automatic payment service, the buyer tradingaccount including information of the buyer financial account.

In some embodiments, the first payment is an initial payment for theorder, and the first payment condition includes a validation of theorder. The second payment is a remaining payment for the order, and thesecond payment condition includes at least one of: a bill of landingassociated with the order having been submitted by the seller on thetrading platform, the submitted bill of landing having been confirmed bythe buyer on the trading platform, an invoice associated with the orderhaving been generated by the blockchain network, the generated invoicehaving been confirmed by the buyer, or a consensus having been reachedbetween the buyer and the seller on the order.

FIG. 13C is a flowchart illustrating an example of a process 1350 formanaging blockchain-based transaction trading services that can beexecuted by a blockchain-based trustable trading and financing system(e.g., the blockchain-based trustable trading and financing system 300of FIG. 3) in accordance with embodiments of this specification. Theblockchain-based trustable trading and financing system can include ablockchain network. The blockchain network can be a public, private, orconsortium blockchain network. In some embodiments, the blockchainnetwork can be the blockchain network 102 of FIG. 1, the blockchainnetwork 212 of FIG. 2, or the blockchain network 320 of FIG. 3. Theblockchain network can be composed of a plurality of trustable nodes.Each trustable node can correspond to a respective participant of tradein the blockchain-based trustable trading and financing system. In someembodiments, one or more of the steps of the process 1350 can beperformed by a trustable network node of the blockchain network (e.g.,the trading platform node 321, the buyer bank node 322, or the sellerbank node 324). In some embodiments, one or more of the steps of theprocess 1350 can be performed by a computing device connected to thetrustable network node of the blockchain network (e.g., the tradingplatform 310, a computing device of the buyer bank 330, or a computingdevice of the seller bank node 324). In some embodiments, one or more ofthe steps of the process 1300 can be performed by a combination or anintegration of a trustable network node of the blockchain network (e.g.,the trading platform node 321) and the computing device connected to thetrustable network node of the blockchain network (e.g., the tradingplatform 310). In some embodiments, one or more of the steps of theprocess 1350 can be performed according to the techniques described withrespect to the processes 500, 600, 700, 1000, 1100, and/or 1200.

At 1352, order data of an order between a buyer and a seller is storedon a blockchain of the blockchain network for the order. The order dataincludes one or more payment conditions for the order and data of atrustable undertaking service (TU) for the order. The order data can bestored by a trustable trading platform node corresponding to a tradingplatform. The trading platform is configured to provide blockchain-basedtrustable trading services between the buyer and the seller. The orderdata can be stored on the blockchain after the order is confirmed by thebuyer and the seller on the trading platform. The TU service for theorder is guaranteed by a buyer financial institution that automaticallymakes a payment on behalf of the buyer based on a credit of the buyer inthe buyer financial institution to a seller financial institutionassociated with the seller in response to that a condition specified ina smart contract deployed on the blockchain is met.

The plurality of trustable nodes can include a trading platform nodecorresponding to the trading platform. The plurality of trustable nodescan include a buyer financial institution node corresponding to thebuyer financial institution. The plurality of trustable nodes caninclude a seller financial institution node corresponding to the sellerfinancial institution.

In some embodiments, one of the buyer financial institution and theseller financial institution is an offshore entity, and the other one ofthe buyer financial institution and the seller financial institution isan onshore entity. The offshore entity and the onshore entity aresubject to different financial regulations. The buyer financialinstitution node corresponding to the buyer financial institution andthe seller financial institution node corresponding to the sellerfinancial institution belong to the same blockchain network of theplurality of trustable nodes.

At 1354, a trustable undertaking certificate for the order is generatedbased on the order data including the TU data. In some embodiments, thetrustable undertaking certificate includes at least one of: anidentifier of the trustable undertaking certificate, an effective timeof the trustable undertaking certificate, the corresponding paymentcondition for the order payment, information of the order including atleast one of an order identifier, a total cost of the order, or productinformation, logistics information for the order including at least oneof a shipping method, a trade term, a shipping cost, or a shippinginsurance cost, information of the buyer and the seller, information ofthe buyer financial institution and the seller financial institution, orinformation of the buyer financial account in the buyer financialinstitution and the seller financial account in the seller financialinstitution.

At 1356, the trustable undertaking certificate for the order is storedon the blockchain.

In some embodiments, the trading platform node is configured to: verifywhether the buyer is authorized for the TU service for the order on thetrading platform with a computing device of the buyer financialinstitution through the buyer financial institution node. In someembodiments, generating the trustable undertaking certificate for theorder on the blockchain is in response to verifying that the buyer isauthorized for the corresponding TU service for the order guaranteed bythe buyer financial institution.

In some embodiments, the trading platform node is configure to submit averification request with the trustable undertaking certificate to acomputing device of the buyer financial institution through the buyerfinancial institution node, and the buyer financial institution isconfigured to verify whether the buyer is authorized for thecorresponding TU service for the order based on the trustableundertaking certificate.

In some embodiments, the trading platform node is configured to: inresponse to verifying that the buyer is authorized for the correspondingTU service for the order guaranteed by the buyer financial institution,transmit a verification message to the trading platform confirming thatthe buyer is authorized for the corresponding TU service for the order.

In some embodiments, the trading platform is configured to validate theorder after receiving the verification message from the trading platformnode.

In some embodiments, the trading platform node is configured to transmitthe verification request after storing the order data of the order onthe blockchain.

In some embodiments, the corresponding payment condition is determinedbased on the corresponding TU service for the order.

At 1358, the trustable undertaking certificate is transmitted to acomputing device of a seller financial institution to determine whetherto approve a financing request of the seller based on the trustableundertaking certificate.

In some embodiments, the seller financial institution node is configuredto: receive approval data from the computing device of the sellerfinancial institution, the approval data indicating that the sellerfinancial institution has approved the financing request of the sellerfor a financing amount based on the trustable undertaking certificate,and store the approval data on the blockchain, where the approval datareferences the trustable undertaking certificate.

In some embodiments, the seller financial institution node is configuredto: receive financing payment data from the computing device of theseller financial institution, the financing payment data confirming thata financing amount associated with the financing request has been paidby the seller financial account in the seller financial institution, andstore the financing payment data on the blockchain.

In some embodiments, the seller financial institution node is configuredto: receive payment reception data from the computing device of theseller financial institution, the payment reception data confirming thatthe order payment for the order has been received by the sellerfinancial account in the seller financial institution from the buyerfinancial institution, and store the payment reception data on theblockchain.

In some embodiments, the trading platform node is configured to:generate a corresponding smart contract for the order based on the orderdata of the order. The corresponding smart contract includes anautomatic function that automatically instructs the buyer financialinstitution to make an order payment for the order to the selleraccording to the TU service for the order in response to determiningthat a corresponding payment condition for the order payment is met.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract to automatically instructthe computing device of the buyer financial institution to make theorder payment to the seller according to the TU service for the order inresponse to determining that the corresponding payment condition for theorder payment is met.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract to generate an automaticpayment command in response to determining that the correspondingpayment condition for the order payment is met, the automatic paymentcommand instructing the computing device of the buyer financialinstitution to make the order payment to the seller according to thecorresponding trustable undertaking service for the order; and transmitthe automatic payment command to the computing device of the buyerfinancial institution.

In some embodiments, the blockchain network is configured to: executethe corresponding smart contract to automatically instruct the computingdevice of the buyer financial institution to make the order payment tothe seller according to the corresponding TU service for the order inresponse to determining that a predetermined time has reached or apredetermined time period has lapsed after the corresponding paymentcondition is met.

In some embodiments, the predetermined time or the predetermined timeperiod is determined based on the TU service for the order.

In some embodiments, the one or more payment conditions includes a firstpayment condition for a first payment for the order and a second paymentcondition for a second payment for the order. The second payment is theorder payment made according to the TU service for the order, and thesecond condition includes the corresponding payment condition.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract to automatically instructthe computing device of the buyer financial institution to make thefirst payment to the seller according to a trustable automatic paymentservice for the buyer provided by the buyer financial institution inresponse to determining that the first payment condition for the firstpayment is met, and execute the corresponding smart contract toautomatically instruct the computing device of the buyer financialinstitution to make the second payment to the seller according to thecorresponding TU service for the order in response to determining thatthe second payment condition for the second payment is met.

In some embodiments, the first payment is an initial payment for theorder, and the first payment condition includes a validation of theorder. The second payment is a remaining payment for the order, and thesecond payment condition includes at least one of: a bill of landingassociated with the order having been submitted by the seller on thetrading platform, the submitted bill of landing having been confirmed bythe buyer on the trading platform, an invoice associated with the orderhaving been generated by the blockchain network, the generated invoicehaving been confirmed by the buyer, or a consensus having been reachedbetween the buyer and the seller on the order.

In some embodiments, the trading platform node is configured to: afterthe buyer logs in a buyer trading account on the trading platform,communicate with the computing device of the buyer financial institutionthrough the buyer financial institution node to verify whether a buyerfinancial account of the buyer in the buyer financial institution isqualified for the trustable automatic payment service, the buyer tradingaccount including information of the buyer financial account.

In some embodiments, the corresponding smart contract further includesan order status update function that automatically updates a status ofthe order in response to determining the status of the order is changedbased on order status data uploaded to the corresponding blockchain.

In some embodiments, the status of the order indicates at least one of:products associated with the order having been prepared or shipped bythe seller, the products having been inspected by a customs office, theproducts being transported by at least one logistics provider, a bill oflanding associated with the order having been submitted by the seller onthe trading platform, the submitted bill of landing having beenconfirmed by the buyer on the trading platform, an invoice associatedwith the order having been generated by the blockchain network, thegenerated invoice having been confirmed by the buyer, a consensus havingbeen reached between the buyer and the seller on the order, theautomatic payment having been made by the buyer financial institution,the automatic payment having been received by the seller, or theproducts having been received by the buyer.

In some embodiments, the blockchain networks of the plurality oftrustable nodes further includes at least one of: a customs office nodecorresponding to the customs office, the order status data includingcustom data uploaded to the corresponding blockchain by the customsoffice node, or a logistic provider node corresponding to the at leastone logistics provider, the order status data including logistic datauploaded to the corresponding blockchain by the logistic provide node.

In some embodiments, the order status data includes at least one oflogistics data, supplychain data, customs data, bill of landing data, orpayment data.

FIG. 14A depicts examples of modules of an apparatus 1400 in accordancewith embodiments of this specification. The apparatus 1400 can be anexample of an embodiment of a blockchain network configured to manageblockchain-based trustable trading services. The apparatus 1400 cancorrespond to the embodiments described above, and the apparatus 1400includes the following: a storing module 1402 that store order data ofan order between a buyer and a seller on a blockchain of the blockchainnetwork for the order after the order is confirmed by the buyer and theseller on a trading platform, the order data including one or morepayment conditions for the order; a verifying module 1404 that verifiesthe buyer has a trustable automatic payment service guaranteed by abuyer financial institution that automatically makes a payment on behalfof the buyer in response to that a condition specified in a smartcontract deployed on the blockchain is met; a generating module 1406that generates a corresponding smart contract for the order based on theorder data of the order, the corresponding smart contract including anautomatic function that automatically instructs the buyer financialinstitution to make an order payment for the order to the seller inresponse to determining that a corresponding payment condition for theorder payment is met; a receiving module 1408 that receives order statusdata of the order uploaded to the blockchain; and an executing module1410 that executes the corresponding smart contract to automaticallyinstruct a computing device of the buyer financial institution to makethe order payment to the seller according to the trustable AP service inresponse to determining that the corresponding payment condition for theorder payment is met based on the order status data.

In some embodiments, the apparatus 1400 includes a buyer financialinstitution node corresponding to the buyer financial institution. Thebuyer financial institution node is configured to communicate with thecomputing device of the buyer financial institution to verify that thebuyer has the trustable automatic payment service guaranteed by thebuyer financial institution and execute the corresponding smartcontract.

In some embodiments, the buyer financial institution node is configuredto receive order payment data confirming that the buyer financialinstitution has made the order payment to the seller and store the orderpayment data on the corresponding blockchain.

In some embodiments, the trading platform is configured to: receive theorder payment data from the corresponding blockchain; and feed back apayment status to the buyer and the seller based on the order paymentdata.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract to automatically instructthe computing device of the buyer financial institution to make theorder payment to the seller in response to determining that apredetermined time has reached or a predetermined time period has lapsedafter the corresponding payment condition for the order payment is met.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract to generate an automaticpayment command in response to determining that the correspondingpayment condition for the order payment is met; and transmit theautomatic payment command to the computing device of the buyer financialinstitution, the automatic payment command instructing the computingdevice of the buyer financial institution to make the order payment tothe seller according to the trustable automatic payment service.

In some embodiments, the buyer financial institution node is configuredto store order payment data on the corresponding blockchain, the orderpayment data confirming that the order payment has been made by thebuyer financial institution to the seller.

In some embodiments, the buyer has a buyer financial account in thebuyer financial institution, and the seller has a seller financialaccount in a seller financial institution. The buyer financialinstitution node is configured to execute the corresponding smartcontract to automatically instruct the computing device of the buyerfinancial institution to make the order payment directly to the sellerfinancial account in the seller financial institution, without goingthrough the trading platform, in response to determining that thecorresponding payment condition for the order payment is met.

In some embodiments, the apparatus 1400 includes a seller financialinstitution node corresponding to the seller financial institution.

In some embodiments, one of the buyer financial institution and theseller financial institution is an offshore entity, and the other one ofthe buyer financial institution and the seller financial institution isan onshore entity. The offshore entity and the onshore entity aresubject to different financial regulations, and the buyer financialinstitution node corresponding to the buyer financial institution andthe seller financial institution node corresponding to the sellerfinancial institution belong to the same blockchain network of theplurality of trustable nodes.

In some embodiments, the buyer financial institution is configured to:in response to the automatic payment command, transfer a digital valuecorresponding to the order payment to the seller financial institution.

In some embodiments, the seller financial institution node is configuredto: store payment reception data on the corresponding blockchain, thepayment reception data confirming that the order payment has beenreceived by the seller financial account in the seller financialinstitution from the buyer financial institution.

In some embodiments, the apparatus 1400 includes a trading platform nodecorresponding to the trading platform.

In some embodiments, the trading platform node is configured to generatethe corresponding smart contract for the order from a smart contracttemplate based on the order data, the smart contract template includinga plurality of functions for the trustable trading services, and ingenerating the corresponding smart contract for the order, the tradingplatform node is configured to call one or more of the plurality offunctions in the smart contract template and use the order data as inputto the one or more of the plurality of functions in the smart contracttemplate.

In some embodiments, the trading platform node is configured to: afterthe buyer logs in a buyer trading account on the trading platform,communicate with the buyer financial institution node to verify whethera buyer financial account of the buyer in the buyer financialinstitution is qualified for the trustable automatic payment service onthe trading platform, the buyer trading account including information ofthe buyer financial account.

In some embodiments, the trading platform is configured to: permit thebuyer to draft or review the order on the trading platform in responseto determining that the buyer financial account is qualified for thetrustable automatic payment service.

In some embodiments, the corresponding smart contract further includes:an order status update function that automatically updates a status ofthe order in response to determining the status of the order is changedbased on order status data uploaded to the corresponding blockchain.

In some embodiments, the order status data includes at least one oflogistics data, supplychain data, customs data, bill of landing data, orpayment data.

In some embodiments, the status of the order indicates at least one of:products associated with the order having been prepared or shipped bythe seller, the products having been inspected by a customs office, theproducts being transported by at least one logistics provider, a bill oflanding associated with the order having been submitted by the seller onthe trading platform, the submitted bill of landing having beenconfirmed by the buyer on the trading platform, an invoice associatedwith the order having been generated by the blockchain network, thegenerated invoice having been confirmed by the buyer, a consensus havingbeen reached between the buyer and the seller on the order, theautomatic payment having been made by the buyer financial institution,the automatic payment having been received by the seller, or theproducts having been received by the buyer.

In some embodiments, the apparatus 1400 further includes at least oneof: a customs office node corresponding to a customs office, where theorder status data includes custom data uploaded to the correspondingblockchain by the customs office node, or a logistic provider nodecorresponding to at least one logistics provider, where the order statusdata include logistic data uploaded to the corresponding blockchain bythe logistic provide node.

In some embodiments, the one or more payment conditions includes a firstpayment condition for a first payment for the order and a second paymentcondition for a second payment for the order. The buyer financialinstitution node is configured to: execute the corresponding smartcontract to automatically instruct the computing device of the buyerfinancial institution to make the first payment to the seller inresponse to determining that the first condition for the first paymentis met, and execute the corresponding smart contract to automaticallyinstruct the computing device of the buyer financial institution to makethe second payment to the seller in response to determining that thesecond condition for the second payment is met.

In some embodiments, the first payment is an initial payment of theorder, and the first payment condition includes the order having beenvalidated on the trading platform. The second payment is a remainingpayment of the order, and the second payment condition includes at leastone of: a bill of landing associated with the order having beensubmitted by the seller on the trading platform, the submitted bill oflanding having been confirmed by the buyer on the trading platform, aninvoice associated with the order having been generated by theblockchain network, the generated invoice having been confirmed by thebuyer, or a consensus having been reached between the buyer and theseller on the order.

FIG. 14B depicts examples of modules of an apparatus 1430 in accordancewith embodiments of this specification. The apparatus 1430 can be anexample of an embodiment of a blockchain network configured to manageblockchain-based trustable trading services. The apparatus 1430 cancorrespond to the embodiments described above, and the apparatus 1430includes the following: a storing module 1432 that store order data ofan order between a buyer and a seller on a blockchain of the blockchainnetwork for the order after the order is confirmed by the buyer and theseller on a trading platform, the order data including one or morepayment conditions for the order and data of a trustable undertakingservice (TU) for the order; a verifying module 1434 that verifies thebuyer has the TU guaranteed by a buyer financial institution thatautomatically makes a payment on behalf of the buyer in response to thata condition specified in a smart contract deployed on the blockchain ismet; a generating module 1436 that generates a corresponding smartcontract for the order based on the order data of the order, thecorresponding smart contract including an automatic function thatautomatically instructs the buyer financial institution to make an orderpayment for the order to the seller according to the TU service for theorder in response to determining that a corresponding payment conditionfor the order payment is met; a receiving module 1438 that receivesorder status data of the order uploaded to the blockchain; and anexecuting module 1440 that executes the corresponding smart contract toautomatically instruct a computing device of the buyer financialinstitution to make the order payment to the seller according to the TUin response to determining that the corresponding payment condition forthe order payment is met based on the order status data.

In some embodiments, the apparatus 1430 includes a buyer financialinstitution node corresponding to the buyer financial institution. Thebuyer financial institution node is configured to: receive order paymentdata confirming that the buyer financial institution has successfullymade the order payment to the seller according to the corresponding TUservice for the order; and store the order payment data on thecorresponding blockchain.

In some embodiments, the apparatus 1430 includes a seller financialinstitution node corresponding to a seller financial institution. Theseller has a seller financial account in the seller financialinstitution, and the seller financial institution node is configured tostore payment reception data on the corresponding blockchain, thepayment reception data confirming that the order payment for the orderhas been received by the seller financial account in the sellerfinancial institution from the buyer financial institution.

In some embodiments, the apparatus 1430 includes a trading platform nodecorresponding to the trading platform. The trading platform node isconfigured to: determine, based on the TU data, that the buyer selectsto use the corresponding TU service for the order on the tradingplatform, and transmit a request to the computing device of the buyerfinancial institution through the buyer financial institution node, therequest requesting the buy financial institution to verify whether thebuyer is qualified for the corresponding TU service for the orderguaranteed by the buyer financial institution.

In some embodiments, the trading platform is configured to provide auser interface for receiving user input of the order data, and the userinterface includes a selection to use the corresponding TU service forthe order.

In some embodiments, the buyer financial institution node is configuredto: receive verification data from the computing device of the buyerfinancial institution, the verification data confirming that the buyerhas the corresponding TU service for the order guaranteed by the buyerfinancial institution, and store the verification data on thecorresponding blockchain.

In some embodiments, the trading platform is configured to: determine,based on the verification data stored on the corresponding blockchain,that the buyer has the corresponding TU service for the order guaranteedby the buyer financial institution, and validate the order afterdetermining that the buyer has the corresponding TU service for theorder guaranteed by the buyer financial institution.

In some embodiments, the trading platform node is configured to transmitthe request after storing the order data of the order on thecorresponding blockchain.

In some embodiments, the corresponding payment condition for the orderpayment is determined based on the corresponding TU service for theorder.

In some embodiments, the buyer financial institution node is configuredto execute the corresponding smart contract to automatically instructthe computing device of the buyer financial institution to make theorder payment to the seller according to the corresponding TU servicefor the order in response to determining that a predetermined time hasreached or a predetermined time period has lapsed after thecorresponding payment condition for the order payment is met.

In some embodiments, the predetermined time or the predetermined timeperiod is determined based on the corresponding TU service for theorder.

In some embodiments, the one or more payment conditions includes a firstpayment condition for a first payment for the order and a second paymentcondition for a second payment for the order. The second payment is theorder payment made according to the corresponding TU service, and thesecond payment condition includes the corresponding payment condition.The buyer financial institution node is configured to execute thecorresponding smart contract to automatically instruct the computingdevice of the buyer financial institution to make the second payment tothe seller according to the corresponding TU service for the order inresponse to determining that the second payment condition for the secondpayment is met.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract to automatically instructthe computing device of the buyer financial institution to make thefirst payment to the seller according to a trustable automatic paymentservice for the buyer provided by the buyer financial institution inresponse to determining that the first payment condition for the firstpayment is met.

In some embodiments, the trading platform node is configured to: afterthe buyer logs in a buyer trading account on the trading platform,communicate with the computing device of the buyer financial institutionthrough the buyer financial institution node to verify whether a buyerfinancial account of the buyer in the buyer financial institution isqualified for the trustable automatic payment service, the buyer tradingaccount including information of the buyer financial account.

In some embodiments, the first payment is an initial payment for theorder, and the first payment condition includes a validation of theorder. The second payment is a remaining payment for the order, and thesecond payment condition includes at least one of: a bill of landingassociated with the order having been submitted by the seller on thetrading platform, the submitted bill of landing having been confirmed bythe buyer on the trading platform, an invoice associated with the orderhaving been generated by the blockchain network, the generated invoicehaving been confirmed by the buyer, or a consensus having been reachedbetween the buyer and the seller on the order.

In some embodiments, the corresponding smart contract further includesan order status update function that automatically updates a status ofthe order in response to determining the status of the order is changedbased on order status data uploaded to the corresponding blockchain.

In some embodiments, the status of the order indicates at least one of:products associated with the order having been prepared or shipped bythe seller, the products having been inspected by a customs office, theproducts being transported by at least one logistics provider, a bill oflanding associated with the order having been submitted by the seller onthe trading platform, the submitted bill of landing having beenconfirmed by the buyer on the trading platform, an invoice associatedwith the order having been generated by the blockchain network, thegenerated invoice having been confirmed by the buyer, a consensus havingbeen reached between the buyer and the seller on the order, theautomatic payment having been made by the buyer financial institution,the automatic payment having been received by the seller, or theproducts having been received by the buyer.

In some embodiments, the blockchain networks of the plurality oftrustable nodes further includes at least one of: a customs office nodecorresponding to the customs office, the order status data includingcustom data uploaded to the corresponding blockchain by the customsoffice node, or a logistic provider node corresponding to the at leastone logistics provider, the order status data including logistic datauploaded to the corresponding blockchain by the logistic provide node.

In some embodiments, the order status data includes at least one oflogistics data, supplychain data, customs data, bill of landing data, orpayment data.

FIG. 14C depicts examples of modules of an apparatus 1450 in accordancewith embodiments of this specification. The apparatus 1450 can be anexample of an embodiment of a blockchain network configured to manageblockchain-based trustable trading services. The apparatus 1450 cancorrespond to the embodiments described above, and the apparatus 1450includes the following: a first storing module 1452 that store orderdata of an order between a buyer and a seller on a blockchain of theblockchain network for the order after the order is confirmed by thebuyer and the seller on a trading platform, the order data including oneor more payment conditions for the order and data of a trustableundertaking (TU) service for the order, the TU service being guaranteedby a buyer financial institution that automatically makes a payment onbehalf of the buyer in response to that a condition specified in a smartcontract deployed on the blockchain is met; a generating module 1454that generates a trustable undertaking certificate for the order basedon the order data including the TU data; a second storing module 1456that stores the trustable undertaking certificate for the order on theblockchain; and a transmitting module 1458 that transmits the trustableundertaking certificate to a computing device of a seller financialinstitution to determine whether to approve a financing request of theseller based on the trustable undertaking certificate.

The apparatus 1450 includes a plurality of trustable nodes. In someembodiments, the apparatus 1450 includes a trading platform nodecorresponding to the trading platform. In some embodiments, theapparatus 1450 includes a buyer financial institution node correspondingto the buyer financial institution. In some embodiments, the apparatus1450 includes a seller financial institution node corresponding to theseller financial institution.

In some embodiments, one of the buyer financial institution and theseller financial institution is an offshore entity, and the other one ofthe buyer financial institution and the seller financial institution isan onshore entity. The offshore entity and the onshore entity aresubject to different financial regulations. The buyer financialinstitution node corresponding to the buyer financial institution andthe seller financial institution node corresponding to the sellerfinancial institution belong to the same blockchain network of theplurality of trustable nodes.

In some embodiments, the seller financial institution node is configuredto: receive approval data from the computing device of the sellerfinancial institution, the approval data indicating that the sellerfinancial institution has approved the financing request of the sellerfor a financing amount based on the trustable undertaking certificate,and store the approval data on the blockchain, where the approval datareferences the trustable undertaking certificate.

In some embodiments, the seller financial institution node is configuredto: receive financing payment data from the computing device of theseller financial institution, the financing payment data confirming thata financing amount associated with the financing request has been paidby the seller financial account in the seller financial institution, andstore the financing payment data on the blockchain.

In some embodiments, the trustable undertaking certificate includes atleast one of: an identifier of the trustable undertaking certificate, aneffective time of the trustable undertaking certificate, thecorresponding payment condition for the order payment, information ofthe order including at least one of an order identifier, a total cost ofthe order, or product information, logistics information for the orderincluding at least one of a shipping method, a trade term, a shippingcost, or a shipping insurance cost, information of the buyer and theseller, information of the buyer financial institution and the sellerfinancial institution, or information of the buyer financial account inthe buyer financial institution and the seller financial account in theseller financial institution.

In some embodiments, the seller financial institution node is configuredto: receive payment reception data from the computing device of theseller financial institution, the payment reception data confirming thatthe order payment for the order has been received by the sellerfinancial account in the seller financial institution from the buyerfinancial institution, and store the payment reception data on theblockchain.

In some embodiments, the trading platform node is configured to:generate a corresponding smart contract for the order based on the orderdata of the order. The corresponding smart contract includes anautomatic function that automatically instructs the buyer financialinstitution to make an order payment for the order to the selleraccording to the corresponding TU service for the order in response todetermining that a corresponding payment condition for the order paymentis met.

In some embodiments, the trading platform node is configured to: verifywhether the buyer is authorized for the corresponding TU service for theorder on the trading platform with a computing device of the buyerfinancial institution through the buyer financial institution node.

In some embodiments, generating the trustable undertaking certificatefor the order on the blockchain is in response to verifying that thebuyer is authorized for the corresponding TU service for the orderguaranteed by the buyer financial institution.

In some embodiments, the trading platform node is configure to submit averification request with the trustable undertaking certificate to acomputing device of the buyer financial institution through the buyerfinancial institution node, and the buyer financial institution isconfigured to verify whether the buyer is authorized for thecorresponding TU service for the order based on the trustableundertaking certificate.

In some embodiments, the trading platform node is configured to: inresponse to verifying that the buyer is authorized for the correspondingTU service for the order guaranteed by the buyer financial institution,transmit a verification message to the trading platform confirming thatthe buyer is authorized for the corresponding TU service for the order.

In some embodiments, the trading platform is configured to validate theorder after receiving the verification message from the trading platformnode.

In some embodiments, the trading platform node is configured to transmitthe verification request after storing the order data of the order onthe blockchain.

In some embodiments, the corresponding payment condition is determinedbased on the corresponding TU service for the order.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract, where executing thecorresponding smart contract includes automatically instructing thecomputing device of the buyer financial institution to make the orderpayment to the seller according to the corresponding TU service for theorder in response to determining that the corresponding paymentcondition for the order payment is met.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract to generate an automaticpayment command in response to determining that the correspondingpayment condition for the order payment is met, the automatic paymentcommand instructing the computing device of the buyer financialinstitution to make the order payment to the seller according to thecorresponding trustable undertaking service for the order; and transmitthe automatic payment command to the computing device of the buyerfinancial institution.

In some embodiments, the blockchain network is configured to: executethe corresponding smart contract to automatically instruct the computingdevice of the buyer financial institution to make the order payment tothe seller according to the corresponding TU service for the order inresponse to determining that a predetermined time has reached or apredetermined time period has lapsed after the corresponding paymentcondition is met.

In some embodiments, the predetermined time or the predetermined timeperiod is determined based on the corresponding TU service for theorder.

In some embodiments, the one or more payment conditions includes a firstpayment condition for a first payment for the order and a second paymentcondition for a second payment for the order. The second payment is theorder payment made according to the TU service for the order, and thesecond condition includes the corresponding payment condition.

In some embodiments, the buyer financial institution node is configuredto: execute the corresponding smart contract to automatically instructthe computing device of the buyer financial institution to make thefirst payment to the seller according to a trustable automatic paymentservice for the buyer provided by the buyer financial institution inresponse to determining that the first payment condition for the firstpayment is met, and execute the corresponding smart contract toautomatically instruct the computing device of the buyer financialinstitution to make the second payment to the seller according to thecorresponding TU service for the order in response to determining thatthe second payment condition for the second payment is met.

In some embodiments, the first payment is an initial payment for theorder, and the first payment condition includes a validation of theorder. The second payment is a remaining payment for the order, and thesecond payment condition includes at least one of: a bill of landingassociated with the order having been submitted by the seller on thetrading platform, the submitted bill of landing having been confirmed bythe buyer on the trading platform, an invoice associated with the orderhaving been generated by the blockchain network, the generated invoicehaving been confirmed by the buyer, or a consensus having been reachedbetween the buyer and the seller on the order.

In some embodiments, the trading platform node is configured to: afterthe buyer logs in a buyer trading account on the trading platform,communicate with the computing device of the buyer financial institutionthrough the buyer financial institution node to verify whether a buyerfinancial account of the buyer in the buyer financial institution isqualified for the trustable automatic payment service, the buyer tradingaccount including information of the buyer financial account.

In some embodiments, the corresponding smart contract further includesan order status update function that automatically updates a status ofthe order in response to determining the status of the order is changedbased on order status data uploaded to the corresponding blockchain.

In some embodiments, the status of the order indicates at least one of:products associated with the order having been prepared or shipped bythe seller, the products having been inspected by a customs office, theproducts being transported by at least one logistics provider, a bill oflanding associated with the order having been submitted by the seller onthe trading platform, the submitted bill of landing having beenconfirmed by the buyer on the trading platform, an invoice associatedwith the order having been generated by the blockchain network, thegenerated invoice having been confirmed by the buyer, a consensus havingbeen reached between the buyer and the seller on the order, theautomatic payment having been made by the buyer financial institution,the automatic payment having been received by the seller, or theproducts having been received by the buyer.

In some embodiments, the blockchain networks of the plurality oftrustable nodes further includes at least one of: a customs office nodecorresponding to the customs office, the order status data includingcustom data uploaded to the corresponding blockchain by the customsoffice node, or a logistic provider node corresponding to the at leastone logistics provider, the order status data including logistic datauploaded to the corresponding blockchain by the logistic provide node.

In some embodiments, the order status data includes at least one oflogistics data, supplychain data, customs data, bill of landing data, orpayment data.

The system, apparatus, module, or unit illustrated in the previousembodiments can be implemented by using a computer chip or an entity, orcan be implemented by using a product having a certain function. Atypical embodiment device is a computer (and the computer can be apersonal computer), a laptop computer, a cellular phone, a camera phone,a smartphone, a personal digital assistant, a media player, a navigationdevice, an email receiving and sending device, a game console, a tabletcomputer, a wearable device, or any combination of these devices.

For an embodiment process of functions and roles of each module in theapparatus, references can be made to an embodiment process ofcorresponding steps in the previous method. Details are omitted here forsimplicity.

Because an apparatus embodiment basically corresponds to a methodembodiment, for related parts, references can be made to relateddescriptions in the method embodiment. The previously describedapparatus embodiment is merely an example. The modules described asseparate parts may or may not be physically separate, and partsdisplayed as modules may or may not be physical modules, may be locatedin one position, or may be distributed on a number of network modules.Some or all of the modules can be selected based on actual demands toachieve the objectives of the solutions of the specification. A personof ordinary skill in the art can understand and implement theembodiments of the present application without creative efforts.

Referring again to FIG. 14A, 14B, or 14C, it can be interpreted asillustrating internal functional modules and a structure of a blockchainnetwork implementation apparatus. An execution body in essence can be anelectronic device, and the electronic device includes the following: oneor more processors; and one or more computer-readable memoriesconfigured to store an executable instruction of the one or moreprocessors. In some embodiments, the one or more computer-readablememories are coupled to the one or more processors and have programminginstructions stored thereon that are executable by the one or moreprocessors to perform algorithms, methods, functions, processes, flows,and procedures, as described in this specification. This specificationalso provides one or more non-transitory computer-readable storage mediacoupled to one or more processors and having instructions stored thereonwhich, when executed by the one or more processors, cause the one ormore processors to perform operations in accordance with embodiments ofthe methods provided herein.

This specification further provides a system for implementing themethods provided herein. The system includes one or more processors, anda computer-readable storage medium coupled to the one or more processorshaving instructions stored thereon which, when executed by the one ormore processors, cause the one or more processors to perform operationsin accordance with embodiments of the methods provided herein.

Embodiments of the subject matter and the actions and operationsdescribed in this specification can be implemented in digital electroniccircuitry, in tangibly-embodied computer software or firmware, incomputer hardware, including the structures disclosed in thisspecification and their structural equivalents, or in combinations ofone or more of them. Embodiments of the subject matter described in thisspecification can be implemented as one or more computer programs, e.g.,one or more modules of computer program instructions, encoded on acomputer program carrier, for execution by, or to control the operationof, data processing apparatus. For example, a computer program carriercan include one or more computer-readable storage media that haveinstructions encoded or stored thereon. The carrier may be a tangiblenon-transitory computer-readable medium, such as a magnetic, magnetooptical, or optical disk, a solid state drive, a random access memory(RAM), a read-only memory (ROM), or other types of media. Alternatively,or in addition, the carrier may be an artificially generated propagatedsignal, e.g., a machine-generated electrical, optical, orelectromagnetic signal that is generated to encode information fortransmission to suitable receiver apparatus for execution by a dataprocessing apparatus. The computer storage medium can be or be part of amachine-readable storage device, a machine-readable storage substrate, arandom or serial access memory device, or a combination of one or moreof them. A computer storage medium is not a propagated signal.

A computer program, which may also be referred to or described as aprogram, software, a software application, an app, a module, a softwaremodule, an engine, a script, or code, can be written in any form ofprogramming language, including compiled or interpreted languages, ordeclarative or procedural languages; and it can be deployed in any form,including as a stand-alone program or as a module, component, engine,subroutine, or other unit suitable for executing in a computingenvironment, which environment may include one or more computersinterconnected by a data communication network in one or more locations.

A computer program may, but need not, correspond to a file in a filesystem. A computer program can be stored in a portion of a file thatholds other programs or data, e.g., one or more scripts stored in amarkup language document, in a single file dedicated to the program inquestion, or in multiple coordinated files, e.g., files that store oneor more modules, sub programs, or portions of code.

Processors for execution of a computer program include, by way ofexample, both general- and special-purpose microprocessors, and any oneor more processors of any kind of digital computer. Generally, aprocessor will receive the instructions of the computer program forexecution as well as data from a non-transitory computer-readable mediumcoupled to the processor.

The term “data processing apparatus” encompasses all kinds ofapparatuses, devices, and machines for processing data, including by wayof example a programmable processor, a computer, or multiple processorsor computers. Data processing apparatus can include special-purposelogic circuitry, e.g., an FPGA (field programmable gate array), an ASIC(application specific integrated circuit), or a GPU (graphics processingunit). The apparatus can also include, in addition to hardware, codethat creates an execution environment for computer programs, e.g., codethat constitutes processor firmware, a protocol stack, a databasemanagement system, an operating system, or a combination of one or moreof them.

The processes and logic flows described in this specification can beperformed by one or more computers or processors executing one or morecomputer programs to perform operations by operating on input data andgenerating output. The processes and logic flows can also be performedby special-purpose logic circuitry, e.g., an FPGA, an ASIC, or a GPU, orby a combination of special-purpose logic circuitry and one or moreprogrammed computers.

Computers suitable for the execution of a computer program can be basedon general or special-purpose microprocessors or both, or any other kindof central processing unit. Generally, a central processing unit willreceive instructions and data from a read only memory or a random accessmemory or both. Elements of a computer can include a central processingunit for executing instructions and one or more memory devices forstoring instructions and data. The central processing unit and thememory can be supplemented by, or incorporated in, special-purpose logiccircuitry.

Generally, a computer will also include, or be operatively coupled toreceive data from or transfer data to one or more storage devices. Thestorage devices can be, for example, magnetic, magneto optical, oroptical disks, solid state drives, or any other type of non-transitory,computer-readable media. However, a computer need not have such devices.Thus, a computer may be coupled to one or more storage devices, such as,one or more memories, that are local and/or remote. For example, acomputer can include one or more local memories that are integralcomponents of the computer, or the computer can be coupled to one ormore remote memories that are in a cloud network. Moreover, a computercan be embedded in another device, e.g., a mobile telephone, a personaldigital assistant (PDA), a mobile audio or video player, a game console,a Global Positioning System (GPS) receiver, or a portable storagedevice, e.g., a universal serial bus (USB) flash drive, to name just afew.

Components can be “coupled to” each other by being commutatively such aselectrically or optically connected to one another, either directly orvia one or more intermediate components. Components can also be “coupledto” each other if one of the components is integrated into the other.For example, a storage component that is integrated into a processor(e.g., an L2 cache component) is “coupled to” the processor.

To provide for interaction with a user, embodiments of the subjectmatter described in this specification can be implemented on, orconfigured to communicate with, a computer having a display device,e.g., a LCD (liquid crystal display) monitor, for displaying informationto the user, and an input device by which the user can provide input tothe computer, e.g., a keyboard and a pointing device, e.g., a mouse, atrackball or touchpad. Other kinds of devices can be used to provide forinteraction with a user as well; for example, feedback provided to theuser can be any form of sensory feedback, e.g., visual feedback,auditory feedback, or tactile feedback; and input from the user can bereceived in any form, including acoustic, speech, or tactile input. Inaddition, a computer can interact with a user by sending documents toand receiving documents from a device that is used by the user; forexample, by sending web pages to a web browser on a user's device inresponse to requests received from the web browser, or by interactingwith an app running on a user device, e.g., a smartphone or electronictablet. Also, a computer can interact with a user by sending textmessages or other forms of message to a personal device, e.g., asmartphone that is running a messaging application, and receivingresponsive messages from the user in return.

This specification uses the term “configured to” in connection withsystems, apparatus, and computer program components. For a system of oneor more computers to be configured to perform particular operations oractions means that the system has installed on it software, firmware,hardware, or a combination of them that in operation cause the system toperform the operations or actions. For one or more computer programs tobe configured to perform particular operations or actions means that theone or more programs include instructions that, when executed by dataprocessing apparatus, cause the apparatus to perform the operations oractions. For special-purpose logic circuitry to be configured to performparticular operations or actions means that the circuitry has electroniclogic that performs the operations or actions.

While this specification contains many specific embodiment details,these should not be construed as limitations on the scope of what isbeing claimed, which is defined by the claims themselves, but rather asdescriptions of features that may be specific to particular embodiments.Certain features that are described in this specification in the contextof separate embodiments can also be realized in combination in a singleembodiment. Conversely, various features that are described in thecontext of a single embodiment can also be realized in multipleembodiments separately or in any suitable subcombination. Moreover,although features may be described above as acting in certaincombinations and even initially be claimed as such, one or more featuresfrom a claimed combination can in some cases be excised from thecombination, and the claim may be directed to a subcombination orvariation of a subcombination.

Similarly, while operations are depicted in the drawings and recited inthe claims in a particular order, this should not be understood asrequiring that such operations be performed in the particular ordershown or in sequential order, or that all illustrated operations beperformed, to achieve desirable results. In certain circumstances,multitasking and parallel processing may be advantageous. Moreover, theseparation of various system modules and components in the embodimentsdescribed above should not be understood as requiring such separation inall embodiments, and it should be understood that the described programcomponents and systems can generally be integrated together in a singlesoftware product or packaged into multiple software products.

Particular embodiments of the subject matter have been described. Otherembodiments are within the scope of the following claims. For example,the actions recited in the claims can be performed in a different orderand still achieve desirable results. As one example, the processesdepicted in the accompanying figures do not necessarily require theparticular order shown, or sequential order, to achieve desirableresults. In some cases, multitasking and parallel processing may beadvantageous.

1. A system for managing blockchain-based trustable transactionservices, comprising: a blockchain network of a plurality of trustablenodes that comprises: a trading platform node corresponding to a tradingplatform for providing blockchain-based trustable trading servicesbetween a buyer and a seller, wherein the buyer is verified to have atrustable automatic payment service guaranteed by a buyer financialinstitution that automatically makes a payment on behalf of the buyer inresponse to that a condition specified in a smart contract deployed on ablockchain of the blockchain network is met; and a buyer financialinstitution node corresponding to the buyer financial institution,wherein the trading platform node is configured to: store order data ofan order on a corresponding blockchain for the order after the order isconfirmed by the buyer and the seller on the trading platform, the orderdata comprising one or more payment conditions for the order; andgenerate a corresponding smart contract for the order based on the orderdata of the order, wherein the corresponding smart contract comprises anautomatic function that automatically instructs the buyer financialinstitution to make an order payment for the order to the seller inresponse to determining that a corresponding payment condition for theorder payment is met; and wherein the buyer financial institution nodeis configured to: communicate with a computing device of the buyerfinancial institution to verify that the buyer has the trustableautomatic payment service guaranteed by the buyer financial institution,and execute the corresponding smart contract, wherein executing thecorresponding smart contract comprises automatically instructing thecomputing device of the buyer financial institution to make the orderpayment to the seller in response to determining that the correspondingpayment condition for the order payment is met.
 2. The system of claim1, wherein the buyer financial institution node is configured to:receive order payment data confirming that the buyer financialinstitution has made the order payment to the seller; and store theorder payment data on the corresponding blockchain.
 3. The system ofclaim 2, wherein the trading platform is configured to: receive theorder payment data from the corresponding blockchain; and provide apayment status to the buyer and the seller based on the order paymentdata.
 4. The system of claim 3, wherein the buyer financial institutionnode is configured to: execute the corresponding smart contract toautomatically instruct the computing device of the buyer financialinstitution to make the order payment to the seller in response todetermining that a predetermined time has reached or a predeterminedtime period has lapsed after the corresponding payment condition for theorder payment is met.
 5. The system of claim 4, wherein the buyer has abuyer financial account in the buyer financial institution, and theseller has a seller financial account in a seller financial institution,and wherein the buyer financial institution node is configured toexecute the corresponding smart contract to automatically instruct thecomputing device of the buyer financial institution to make the orderpayment directly to the seller financial account in the seller financialinstitution, without going through the trading platform, in response todetermining that the corresponding payment condition for the orderpayment is met.
 6. The system of claim 5, wherein the blockchain networkof the plurality of trustable nodes further comprises: a sellerfinancial institution node corresponding to the seller financialinstitution.
 7. The system of claim 6, wherein the buyer financialinstitution node corresponding to the buyer financial institution andthe seller financial institution node corresponding to the sellerfinancial institution belong to the blockchain network of the pluralityof trustable nodes.
 8. The system of claim 1, wherein the tradingplatform node is configured to: after the buyer logs in a buyer tradingaccount on the trading platform, communicate with the buyer financialinstitution node to verify whether a buyer financial account of thebuyer in the buyer financial institution is qualified for the trustableautomatic payment service on the trading platform, the buyer tradingaccount comprising information of the buyer financial account.
 9. Thesystem of claim 8, wherein the corresponding smart contract furthercomprises: an order status update function that automatically updates astatus of the order in response to determining the status of the orderis changed based on order status data uploaded to the correspondingblockchain.
 10. The system of claim 9, wherein the status of the orderindicates at least one of: products associated with the order havingbeen prepared or shipped by the seller, the products having beeninspected by a customs office, the products being transported by atleast one logistics provider, a bill of landing associated with theorder having been submitted by the seller on the trading platform, thesubmitted bill of landing having been confirmed by the buyer on thetrading platform, an invoice associated with the order having beengenerated by the blockchain network, the generated invoice having beenconfirmed by the buyer, a consensus having been reached between thebuyer and the seller on the order, an automatic payment having been madeby the buyer financial institution, the automatic payment having beenreceived by the seller, or the products having been received by thebuyer.
 11. The system of claim 10, wherein the blockchain network of theplurality of trustable nodes further comprises at least one of: acustoms office node corresponding to a customs office, wherein the orderstatus data comprises custom data uploaded to the correspondingblockchain by the customs office node, or a logistic provider nodecorresponding to at least one logistics provider, wherein the orderstatus data comprise logistic data uploaded to the correspondingblockchain by the logistic provider node.
 12. The system claim 1,wherein the one or more payment conditions comprises a first paymentcondition for a first payment for the order and a second paymentcondition for a second payment for the order, and wherein the buyerfinancial institution node is configured to: execute the correspondingsmart contract to automatically instruct the computing device of thebuyer financial institution to make the first payment to the seller inresponse to determining that the first payment condition for the firstpayment is met, and execute the corresponding smart contract toautomatically instruct the computing device of the buyer financialinstitution to make the second payment to the seller in response todetermining that the second payment condition for the second payment ismet.
 13. The system of claim 12, wherein the first payment is an initialpayment of the order, and the first payment condition comprises theorder having been validated on the trading platform, and wherein thesecond payment is a remaining payment of the order, and the secondpayment condition comprises at least one of: a bill of landingassociated with the order having been submitted by the seller on thetrading platform, the submitted bill of landing having been confirmed bythe buyer on the trading platform, an invoice associated with the orderhaving been generated by the blockchain network, the generated invoicehaving been confirmed by the buyer, or a consensus having been reachedbetween the buyer and the seller on the order.
 14. Acomputer-implemented method performed in a blockchain network of aplurality of trusted nodes, comprising: in a trading platform nodecorresponding to a trading platform for providing blockchain-basedtrustable trading services between a buyer and a seller, wherein thebuyer is verified to have a trustable automatic payment serviceguaranteed by a buyer financial institution that automatically makes apayment on behalf of the buyer in response to that a condition specifiedin a smart contract deployed on a blockchain of the blockchain networkis met: and storing order data of an order on a corresponding blockchainfor the order after the order is confirmed by the buyer and the selleron the trading platform, the order data comprising one or more paymentconditions for the order; and generating a corresponding smart contractfor the order based on the order data of the order, wherein thecorresponding smart contract comprises an automatic function thatautomatically instructs the buyer financial institution to make an orderpayment for the order to the seller in response to determining that acorresponding payment condition for the order payment is met; and in abuyer financial institution node corresponding to the buyer financialinstitution: communicating with a computing device of the buyerfinancial institution to verify that the buyer has the trustableautomatic payment service guaranteed by the buyer financial institution;and executing the corresponding smart contract, wherein executing thecorresponding smart contract comprises automatically instructing thecomputing device of the buyer financial institution to make the orderpayment to the seller in response to determining that the correspondingpayment condition for the order payment is met.
 15. Thecomputer-implemented method of claim 14, further comprising: receiving,by the buyer financial institution node, order payment data confirmingthat the buyer financial institution has made the order payment to theseller; and storing, by the buyer financial institution node, the orderpayment data on the corresponding blockchain.
 16. Thecomputer-implemented method of claim 15, further comprising: receiving,by the trading platform, the order payment data from the correspondingblockchain; and providing, by the trading platform, a payment status tothe buyer and the seller based on the order payment data.
 17. Thecomputer-implemented method of claim 16, further comprising: executing,by the buyer financial institution node, the corresponding smartcontract to automatically instruct the computing device of the buyerfinancial institution to make the order payment to the seller inresponse to determining that a predetermined time has reached or apredetermined time period has lapsed after the corresponding paymentcondition for the order payment is met.
 18. The computer-implementedmethod of claim 17, wherein the buyer has a buyer financial account inthe buyer financial institution, and the seller has a seller financialaccount in a seller financial institution, and further comprising:executing, by the buyer financial institution node, corresponding smartcontract to automatically instruct the computing device of the buyerfinancial institution to make the order payment directly to the sellerfinancial account in the seller financial institution, without goingthrough the trading platform, in response to determining that thecorresponding payment condition for the order payment is met.
 19. Thecomputer-implemented method of claim 18, wherein the buyer financialinstitution node corresponding to the buyer financial institution and aseller financial institution node corresponding to the seller financialinstitution belong to the blockchain network of the plurality of trustednodes.
 20. A non-transitory, computer-readable medium storinginstructions executable by a computer system in a blockchain network ofa plurality of trusted nodes, wherein upon such execution: in a tradingplatform node corresponding to a trading platform for providingblockchain-based trustable trading services between a buyer and aseller, wherein the buyer is verified to have a trustable automaticpayment service guaranteed by a buyer financial institution thatautomatically makes a payment on behalf of the buyer in response to thata condition specified in a smart contract deployed on a blockchain ofthe blockchain network is met: and storing order data of an order on acorresponding blockchain for the order after the order is confirmed bythe buyer and the seller on the trading platform, the order datacomprising one or more payment conditions for the order; and generatinga corresponding smart contract for the order based on the order data ofthe order, wherein the corresponding smart contract comprises anautomatic function that automatically instructs the buyer financialinstitution to make an order payment for the order to the seller inresponse to determining that a corresponding payment condition for theorder payment is met; and in a buyer financial institution nodecorresponding to the buyer financial institution: communicating with acomputing device of the buyer financial institution to verify that thebuyer has the trustable automatic payment service guaranteed by thebuyer financial institution; and executing the corresponding smartcontract, wherein executing the corresponding smart contract comprisesautomatically instructing the computing device of the buyer financialinstitution to make the order payment to the seller in response todetermining that the corresponding payment condition for the orderpayment is met.